Minification in a real deployment pipeline
If your project has a build step, minification should live there: Vite and webpack minify CSS in production builds automatically, and PostCSS users typically add cssnano. This tool covers the cases a pipeline doesn’t reach — legacy sites deployed by FTP, CMS theme editors where you paste CSS into a textarea, HTML email styles, and quick experiments where setting up tooling is overkill. Keep the readable source in version control and treat the minified output as a build artifact, never the other way around.
Beautifying for debugging: a workflow
When a layout bug comes from a third-party stylesheet, beautify it before reading. With readable output you can search for the selector in question, trace the cascade, and copy the relevant rule into DevTools for live editing. If the site ships source maps (/*# sourceMappingURL=... */ at the end of the file), prefer those in DevTools — they restore the original file structure. Beautifying is the fallback when no map exists.
What to check after minifying
Minification is semantically safe, but two practical checks are worth a habit:
- Verify the byte savings in the stats readout — if the reduction is tiny, your CSS was already compact and the risk/benefit of an extra manual step may not be worth it.
- Confirm
calc()expressions survived intact. Spaces around+and-insidecalc()are syntactically required; a correct minifier (including this one) preserves them, but it’s the first thing to inspect if a layout shifts after deploying minified CSS from any tool.
For email templates, minify the embedded <style> block but keep inline style="" attributes as they are — some email clients have parsers fussy enough that aggressive whitespace removal inside attributes can change rendering.