Compress CSS for production or format it for readability — regex-powered, instant, 100% in-browser.
CSS minification strips all whitespace, newlines, and comments that are only needed for human readability. It also removes the last semicolon before a closing brace, collapses zero values (e.g.
0px → 0
), shortens hex colors (
#ffffff → #fff
), and merges duplicate spaces in selector lists — all without changing the visual output of the stylesheet.
CSS beautification is the reverse: it reformats minified or poorly formatted CSS into a consistently indented, human-readable structure. Each rule gets its own line, properties are indented under their selector, at-rules like
@media
are properly nested, and blank lines are added between rule blocks for visual separation.
Minified CSS reduces stylesheet file sizes by 30–80% depending on how many comments and how much whitespace the original contains. Smaller files mean faster HTTP transfers, reduced parse time in the browser's CSSOM construction phase, and improved Core Web Vitals scores — particularly FCP and LCP, since render-blocking stylesheets are fetched and parsed before any content is painted.
Gzip finds repeated byte sequences and replaces them with shorter codes. Minification reduces the raw number of bytes before gzip ever runs. The two are complementary — a minified file compresses further with gzip than an unminified one, because removing whitespace and comments creates more opportunities for gzip to find repeatable patterns. In practice, minification alone typically saves 20–60%. Gzip on top of that saves another 60–80% of what remains. Skip minification and you’re leaving meaningful transfer size on the table even with compression enabled.
| Optimisation | What gets removed or shortened | Rough saving | Risk of breakage |
|---|---|---|---|
| Strip whitespace | Spaces, tabs, newlines between tokens | 20–60% | None — whitespace is never semantically significant in CSS |
| Remove comments | All /* ... */ blocks | 5–30% | None, unless the comment is a /*! preserved license comment — see below |
| Shorten colors | #ffffff → #fff, rgb(0,0,0) → #000 | 1–5% | None for hex shortening. Color name normalisation can occasionally conflict with legacy parsers. |
| Remove zero units | 0px → 0, 0em → 0 | Small | None. Per CSS spec, units on zero values are always optional. |
| Drop last semicolon | The ; before a closing } | 1 byte per rule | None in modern browsers. Old IE 6 had bugs here; nothing current. |
| Collapse shorthand | margin-top:0;margin-right:0;... → margin:0 | Significant on verbose CSS | Low, but check calc() values — some aggressive shorthanders misparse them |
License comments: /*! (note the exclamation mark) tells most minifiers to preserve the comment. If you’re shipping CSS that includes open-source code with attribution requirements, check that the original comment uses this format. If it doesn’t, you’re responsible for not stripping it.
You get a minified .css file from a component library or a CMS and need to understand what it’s doing. Paste it here, hit beautify, and you can read the selectors and property cascade. This is the most common practical use for a browser-based beautifier — the actual build tooling question doesn’t apply here at all.
You’ve written a specific animation or keyframe block for a CodePen or a client deliverable and want to know how small it is. Paste it in, get the number, done. No npm install, no config file.
Vite, webpack, Parcel, and esbuild all minify CSS automatically on production builds. If you’re already running one of these, you don’t need a separate minification step — and manually running output through a second minifier won’t help because the bundler has already done it. The only thing you’d add is the risk of the second pass misinterpreting something.
Source maps are essential for debugging minified CSS in production. They map compressed output back to your original source file and line number. This tool doesn’t generate source maps. For production with DevTools debugging, use cssnano (PostCSS plugin) or the clean-css npm package — both support source map output alongside the minified file.
This tool uses regex-based processing, which handles 95% of real-world CSS correctly and is fast. Full AST-based processors like cssnano can safely merge identical rules, deduplicate selectors, and collapse longhand/shorthand properties because they actually parse the CSS structure. If you have complex at-rules, custom properties, or intricate cascade logic, the AST approach is more reliable for aggressive optimisation.
When you’re inheriting a codebase and the CSS is a mess, running it through the beautifier and then reading it top-to-bottom often reveals property conflicts and duplicate selectors that are invisible in the original unformatted file. It’s not a linter, but it makes the structure readable enough that human review becomes productive.
calc(): calc(100% - 20px) is valid; calc(100%-20px) is not. Aggressive whitespace strippers that don’t understand CSS syntax can remove that required space. Most modern minifiers are aware of this, but if you’re using an old tool or find that a minified stylesheet breaks layout, calc() expressions are one of the first things to check.