CSS Minifier and Beautifier
Minification is a small win on top of compression, not a substitute for it
The byte count in your editor is not the byte count on the wire. If your server sends CSS with gzip or brotli, the repetition that makes a stylesheet look bloated (indentation, property names, colour values, the same declarations over and over) is exactly what a compressor collapses. Brotli also ships a built-in dictionary of common web text, while gzip only matches repeats inside a 32 KB window. Minifying first still helps, because there is less input to compress, but the saving measured after compression is much smaller than the saving measured in raw bytes. If text responses are not compressed at all, fix that before worrying about whitespace.
Whitespace is not always noise
Most spaces in CSS are decorative. A few are syntax, and those are where careless stripping goes wrong. Worth checking in the output when you minify hand-written CSS:
- The descendant combinator:
.card pmatches something different from.cardp. calc()requires whitespace on both sides of+and-, socalc(100%-20px)is invalid.*and/carry no such rule.- In a media query the space before the parenthesis has to stay, because
and(tokenises as a function name: writescreen and (min-width:600px). - Text inside quoted strings,
contentvalues andurl()is data, not formatting. CSS has no//comment either, so the slashes in an absolute URL must survive untouched. - Preprocessor source is not CSS. SCSS or LESS with
//comments and nested blocks has no defined behaviour here, so compile it first.
What it changes and what it leaves alone
This is text-level minification. It shortens the file without reasoning about the cascade, so the rules that reach the browser are the rules you wrote.
| Operation | Applied |
|---|---|
| Strip comments | Yes |
| Collapse indentation and redundant spacing | Yes |
| Merge or deduplicate rules | No |
| Reorder declarations | No |
| Remove unused selectors | No |
Nothing here can work out which selectors your pages never use. That needs your markup and runtime coverage, which a text tool does not have.
Beautifying reformats, it does not recover
Expanding a minified file gives one declaration per line and predictable indentation, which is enough to read a rule, find a selector or diff two builds. It cannot bring back comments or your original formatting, because minification deleted them rather than encoded them. A build step can emit a source map that points back at the original file; pasted text leaves no such record, so keep the readable source in version control and treat the minified file as a build output.
Share this tool with friends
Free to use, no sign-up, works on any phone.
Frequently Asked Questions
Yes, but judge it on compressed bytes. gzip and brotli already collapse the repetition that dominates a stylesheet, so stripping whitespace and comments first mostly removes text the compressor was going to handle anyway. A saving usually survives, because there is less input to compress, but it is a small share of what is actually transferred rather than the headline number your editor shows. Compress both versions the same way your server does, compare those figures, then decide whether the extra build step earns its place.
Correctly implemented text-level minification of valid CSS is safe, because it removes only comments and spacing that carries no meaning. Breakage comes from the places where a space is part of the syntax: descendant combinators, the + and - operators inside calc(), the space before the parenthesis in a media query, and text inside quoted strings or url(). Input that is not plain CSS, such as SCSS using // comments, is a separate hazard. Load the minified file on a real page before shipping it.
No. Deciding that a selector is unused means knowing every page and template, plus the classes your JavaScript applies at runtime, and a text tool sees only the stylesheet you paste in. The browser's coverage panel reports unused bytes for the pages and interactions you actually exercised, so treat it as evidence rather than a verdict; a build-time tool that reads your templates is the more reliable route. This page removes comments and whitespace only.
It is removed, along with every other comment. Licences such as MIT and the BSD family require the copyright notice to stay with copies of the file, so check the terms before you publish the minified version and paste the header back in if it is required. Some build-time minifiers keep comments that open with the /*! marker for this reason, but do not assume a paste-in tool honours that convention. A header costs very little once compressed.
You get the structure back, not the source. Beautifying restores line breaks and indentation so the rules are readable and diffable, but comments and your original formatting are gone for good, because minification deleted them rather than encoded them. A build-time minifier can emit a source map that points back at the original file; text pasted into a web page leaves no such record. If the unminified source still exists anywhere, work from that instead.
Compare compressed sizes, not raw ones. Pipe both versions through the compressor your server uses (gzip -c style.css | wc -c, or brotli -c for brotli) and compare those numbers, matching the compression level your server is configured for, since CLI defaults and server defaults often differ. Alternatively reload the page and read the transferred size in the browser's network panel. The file size shown in your editor overstates the benefit.