CSS Formatter & Minifier

CSS written for humans is full of things a browser does not need: indentation, blank lines between rules, comments explaining a decision, a space after every colon. None of it changes how the page renders, and all of it costs bytes on every page load.

This minifier strips what is safe to strip and leaves what is not. The output is byte-for-byte equivalent in behaviour to the input — the guarantee that matters, because a minifier that saves 30% and breaks one media query has cost you far more than it saved.

Comments, since the browser ignores them. Newlines and indentation between rules and declarations. The space after a colon in a declaration, and the semicolon before a closing brace, both of which are optional.

What survives is anything whose removal could change meaning: whitespace inside strings and url() values, the space between a media feature and the keyword before it, and every character inside a comment marked as preserved.

The subtle case is the space around a parenthesis. In a selector, the space before an opening parenthesis is safe to drop. In an at-rule it is not: @media screen and (min-width:700px) has to keep the space after and, or it becomes the function call and(min-width:700px) and the whole media query is discarded by the parser.

This minifier tracks the two directions separately — which characters license dropping the space that follows them, and which license dropping the space before them — rather than treating a parenthesis as a single rule. Keeping a space is always safe; removing the wrong one silently breaks the file.

Typically 20–35% of the raw file, depending on how heavily commented the source is. On top of that your server almost certainly serves CSS with gzip or brotli compression, which already handles repeated whitespace efficiently.

The honest figure is therefore the size after compression, where minification usually adds a further few percent rather than a third. Worth doing, and not the thing that will make a slow page fast — that is nearly always images and JavaScript.

The Beautify direction is the one you want when a stylesheet arrives as a single line — pulled out of a bundle, copied from a devtools panel, or written by a tool that never expected a human to read it. Rules get one line each, declarations are indented, and a comma-separated selector list is broken so each selector sits on its own line, which is what makes a long list scannable.

It changes layout and nothing else. Comments are kept, because a formatter that dropped them would be deleting the only documentation most stylesheets have. Strings and unquoted url() values are copied out byte for byte, so a data URI cannot be broken by indentation. Property values are never rewritten: no colour is shortened, no shorthand is expanded, no unit is normalised.

The guarantee that matters is that the two directions agree. Beautifying and then minifying returns the same CSS as minifying the original, which is the property worth having — it means the formatter cannot have changed what the stylesheet does, only how it reads. Formatting is also idempotent, so running it twice gives the same file as running it once.

One deliberate limit: a custom property can hold almost any token stream, braces included, so `--card: {a:1}` is legal CSS. That whole value is treated as opaque rather than read as a nested block, which is the sort of thing a formatter written from regexes gets wrong and silently loses the declaration over.