CSS Minifier & Beautifier
Minify CSS to shrink file size or beautify it with clean indentation, showing the byte saving and what a minifier can and cannot safely remove.
Most of what minifying saves, your server was already saving
Minified CSS looks dramatically smaller, and the percentage the tool above reports is real. It is also not the number that matters, because almost nothing is served uncompressed. Here is this site's own stylesheet — 15,052 bytes of hand-written CSS, measured when this page was built.
| What was done | Bytes sent | Saved |
|---|---|---|
| Nothing | 15,052 | — |
| Minified only | 10,017 | 33.5% |
| Compressed only (brotli) | 3,717 | 75.3% |
| Minified and compressed | 2,492 | 83.4% |
The two savings are nowhere near additive — 33.5% plus 75.3% comes to well over the 83.4% they actually manage together. That is because they are largely the same saving found twice. Whitespace, repeated property names and long selectors are exactly what a compressor is best at; deleting them first means the compressor has less left to find, not that the browser downloads proportionally less.
Of the 12,560 bytes saved in total, compression accounts for 11,335 and minification for 1,225 — the compressor does about 9 times more work.
Which is not the same as saying don't minify
It would be easy to over-read that table. Minifying still removes a further 33.0% of what is genuinely sent over the wire, and a fifth off every stylesheet request is worth having. The honest summary is about order of importance rather than worth: minification is the small optimisation, compression is the large one, and a site that carefully minifies without turning on compression has done the minor half of the job while believing it did the major one.
How much either is worth depends heavily on what the file looks like, which is why a single measurement is not enough to generalise from:
| Kind of stylesheet | Minify alone | Compress alone | Minify on top of compression |
|---|---|---|---|
| Commented source Hand-written, documented, generously spaced. | 61.6% | 90.6% | 52.7% |
| Terse source No comments, already compact. Little left to strip. | 3.7% | 95.9% | 5.0% |
| Generated utilities Machine-written and highly repetitive — a compressor loves this. | 23.9% | 91.4% | 5.8% |
Heavily commented source has a great deal to strip. Machine-generated utility classes are so repetitive that the compressor had already dealt with nearly all of it, so minifying adds little. In every case compression wins by a wide margin, and in every case minifying still helps a bit — the ordering is stable even though the sizes are not.
One practical note: brotli beat gzip on every file tested here, and it is supported by every current browser. If you are choosing where to spend an afternoon on payload size, the order is enable brotli, then minify, then argue about the rest.
How to use
- Paste your CSS.
- Choose minify or beautify.
- Check the size comparison.
- Copy the result or download it.
Frequently asked questions
What does minifying remove?
Whitespace, comments, the last semicolon in each block, and unnecessary units on zero values. More aggressive minifiers also shorten colour values, merge duplicate selectors and reorder properties where the result is provably identical.
Is it worth minifying if the server uses gzip?
Less than people expect. Compression handles repeated whitespace very efficiently, so the difference between minified and formatted CSS after gzip is often only a few per cent. It is still worth doing as part of a build, but it is not where meaningful performance gains come from.
Can minifying break my styles?
Rarely, but the ways it can are worth knowing. Property order matters where declarations conflict, so an over-eager reordering can change the result. Hacks that rely on invalid syntax being ignored by particular browsers are often stripped, which is one more reason not to use them.
Should I keep comments?
Not in the minified output, with one exception: licence comments, conventionally marked so minifiers preserve them. Keep your comments in the source, which is the version anybody maintains, and let the build strip them from what ships.
What actually makes CSS slow?
Not file size, in most cases. Unused rules bloating the file, deeply nested selectors, and layout-triggering properties in animations cost far more than the bytes. Removing CSS you no longer use gives a much larger win than minifying what you keep.
Should I minify by hand?
No. It belongs in the build pipeline so that the source stays readable and the output is regenerated on every change. A hand-minified file drifts from its source almost immediately and becomes unmaintainable.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.