Boneyard Tools

How CSS minification works and what it safely removes

The passes a CSS minifier runs, why strings and url() must be protected, and how much smaller a stylesheet really gets.

What is safe to delete

CSS treats most whitespace as insignificant. Line breaks, indentation and the spaces you add for readability between a property and its value make no difference to how a browser parses the rule. Comments, written between the /* and */ markers, are guidance for humans and are never sent to the rendering engine as meaning. A minifier exploits both facts: it removes every comment and squeezes runs of whitespace down to nothing where it is decorative, keeping only the single spaces that separate two values inside a declaration.

The order of the passes

Order matters because the same characters can mean different things in different places. This minifier first pulls out comments so that a stray /* sequence inside code is handled correctly. It then collapses all remaining whitespace to a single space, removes the spaces hugging the structural characters that separate declarations and selectors, and finally strips the last semicolon before a closing brace because nothing follows it. Each pass is simple on its own, and running them in sequence produces output that is both minimal and still valid CSS.

Why strings and url() are protected

Some whitespace is not decorative at all. A content value like a nonbreaking gap between quotes, or a file path such as url(my image.png) that genuinely contains a space, would be corrupted if the collapse touched it. To prevent that, the tool replaces every quoted string and every url() value with a placeholder before it collapses anything, then puts the originals back at the very end. Because the placeholder uses a backtick, a character that is never valid in raw CSS, the collapse passes cannot accidentally alter it, so your literal values come through byte for byte.

Realistic savings and when to minify

How much you save depends on your source. A terse, hand-optimized file may barely shrink, while a generously commented and indented stylesheet can drop a noticeable share of its bytes. Minification is one part of a wider performance story that also includes gzip or brotli compression on the server, which squeezes the repetitive text further. The usual workflow is to keep a readable source file in version control and minify as a build step, so humans edit the clean version while browsers download the compact one.

Frequently asked questions

Should I minify before or after gzip?

Do both, in that order conceptually. Minify to remove redundant characters, then let the server apply gzip or brotli. They target different redundancy, so together they beat either one alone.

Does minifying hurt CSS readability for debugging?

Yes, minified CSS is hard to read, which is why you keep the original source. Ship the minified file and debug against the readable version, optionally with a source map from your build tool.