What a CSS Minifier Actually Deletes

A stylesheet carries two kinds of bytes: instructions the browser executes and manners for the humans who read it. Minification deletes the second kind — and only the second kind — which is why the result renders identically while weighing less. Seeing exactly which bytes go makes the safety of the process obvious.

Four passes, in order

The minifier runs a fixed sequence of pure deletions. First, comments (/* like this */) disappear entirely. Second, every run of whitespace collapses to a single space. Third, the spaces hugging CSS punctuation — { } : ; , > ~ + — are removed, since none of them is grammar. Fourth, the semicolon just before a closing brace goes away, because it terminates nothing. Braces, colons, semicolons, and combinators themselves are never touched: in CSS, structure is content.

A worked example, character by character

Take a 100-character snippet — a comment, two declarations with spaces before their semicolons, and a generously spaced selector:

/* brand palette */ .card { color: #333 ; margin: 0 auto ; } .btn:hover > span { padding: 4px; }

The minified output is 59 characters — .card{color:#333;margin:0 auto}.btn:hover>span{padding:4px} — a 41% saving. Every pass is visible: the comment is gone, #333 ; became #333;, the final semicolon before } vanished, and .btn:hover > span tightened to .btn:hover>span. One space deliberately survived: in margin:0 auto, the space between two values is grammar — 0auto would be a different, invalid token — so it stays. The tool reports the arithmetic alongside the result — original length, minified length, bytes saved, and the percentage — so the only judgment call left is where the compact form belongs: shipped to browsers, with the readable original kept in version control.

Selectors survive; readability does not

Combinators mark the boundary precisely. The > in .btn > span is meaning — "child of" — and must remain; the spaces around it are layout and must go. The minifier applies that distinction only where CSS makes it mechanical: punctuation-adjacent space is always removable, word-adjacent space inside values never is. That conservative rule is why the output can be trusted on files with custom properties, media queries, or modern selector syntax — nothing is rewritten, only squeezed.

What it deliberately does not do

This is a minifier, not an optimizer. It will not shorten #333333 to #333, merge longhand properties into shorthands, reorder rules, or rename classes — rewrites that save more bytes but can change behavior or break selectors your markup depends on. Pure deletion has a strong property: the output is your stylesheet with characters removed, nothing else. The general trade — and where renaming minifiers fit — is covered in Why Code Is Minified (and When Not To). What the values themselves mean, before anyone squeezes them, is the territory of rem vs em vs px.

CSS minifier or HTML minifier?

The neighboring tool solves a harder problem. A CSS file is essentially all grammar, so "delete the removable" is a mechanical rule applied uniformly. An HTML document mixes grammar with visible text, so its minifier must first classify every byte — is this whitespace between tags, or inside <pre> or <textarea> where it is content? — and preserve whole regions untouched. Feed each tool its own language: the CSS minifier on stylesheets, the HTML one on markup, the JavaScript one on scripts.

Try it yourself

Paste a stylesheet into the CSS Minifier and compare the before-and-after character counts — a hand-formatted file with comments typically sheds a third or more. Then run the same check on markup with the HTML Minifier and on scripts with the JavaScript Minifier, to see how each language loses its bytes differently.