CSS Minifier

CSS minification removes every byte that isn't required for the stylesheet to be interpreted identically: comments, whitespace (newlines, tabs, runs of spaces), and redundant syntax — the last semicolon in a declaration block, units on zero values (0px → 0), and leading zeros in decimals (.5em stays .5em). None of it changes what the browser renders; it all exists for human readability.

The typical saving is 15–40% of the original size, with the range depending on how much whitespace and how many comments the source contained — a heavily commented, generously spaced stylesheet can minify by more than half, while a tight one gains little. Since CSS is render-blocking, those bytes translate directly into faster first paint on repeat visits, once the file is cached.

The byte-level tricks are safe and mechanical: shortening #ff9900 to #f90 where the hex pairs repeat, removing quotes from font names that don't need them, collapsing margin/padding shorthand, and stripping the default medium from font-weight. A minifier that goes further — merging duplicate selectors, removing overridden declarations — starts to approach real optimization, but at the risk of changing semantics.

Removing overridden declarations, for instance, is only safe if specificity and source order are fully accounted for; a careless optimizer can drop a rule that a media query or a more specific selector was relying on. That's why most production minifiers stay conservative: they remove formatting and redundant punctuation only, leaving semantic optimization to human review or dedicated tools.

When CSS is minified, browser dev tools point at line 1, column 30,000 — useless for debugging. Source maps solve this by shipping a sidecar file (a .map JSON) that maps every position in the minified output back to the original file, line and column. Dev tools read the map and show you the original, unminified source even though the browser executed the minified version.

The tradeoff is that source maps are dev-only artifacts: they should be generated in development builds and stripped from production (or at least not publicly linked), because they reveal your original file structure and, if committed, can leak information about code you considered private. Modern build tools generate them automatically; the discipline is controlling where they ship.

Minification belongs in the build step, not the authoring workflow: you write readable CSS, commit readable CSS, and the build pipeline emits the minified version alongside it. In practice that means a CSS minifier plugin in your bundler — lightningcss, cssnano, clean-css, or esbuild's built-in minification — wired into the production build task, with the readable source staying in version control as the single source of truth.

The same pipeline is where related concerns live: autoprefixing, dead-code elimination (tree-shaking unused rules), and bundling. Running them together, in one pass over the stylesheet, avoids the classic bug where a "minified" file was hand-edited and drifted from its source — a stale build artifact that ships bugs the source doesn't have.

Don't minify the CSS you're actively developing or reviewing — diffs against minified output are unreadable, stack traces are meaningless, and the 15–40% saving buys you nothing until the file ships. Similarly, inline <style> blocks small enough to be one-liners are often better left alone: minifying them saves bytes but makes the containing HTML harder to read for no meaningful performance gain.

A subtler rule: minification must never alter specificity or cascade order, because it can silently change which rules win. Safe minifiers reorder nothing — they only strip and shorten. If a build ever changes how a page looks after "just minifying," the culprit is usually a hand-written optimization step (rule merging or declaration removal) that broke the cascade, not the whitespace stripping itself.