It's worth knowing what kind of tool this is before you run production CSS through it: this is a text-transform minifier, not a CSS parser like PostCSS or a build-tool plugin. Minify mode strips comments and collapses whitespace around {, }, :, ;, and , — it doesn't tokenize your CSS into an AST, understand selectors, or restructure rules. Beautify mode does the inverse, re-inserting line breaks and indentation after those same characters. For typical, well-formed CSS, that's exactly what you want and it's fast and safe. For CSS with edge cases — a content property containing a literal { or ; inside a quoted string, for instance — a naive text transform can behave unpredictably in a way a real parser wouldn't, so it's worth diffing the output against the original for anything unusual before shipping it.
Minify vs. beautify
Minify removes everything the browser doesn't need to parse the rules correctly — comments, extra whitespace, and space around punctuation — which is exactly what you want before shipping CSS to production, since every byte removed is one less byte the browser has to download and parse. Beautify does the reverse: it takes compressed or minified CSS and re-expands it with consistent indentation, which is useful when you're reading a third-party library's minified stylesheet or debugging legacy code that's been squashed onto a handful of lines.
When this tool is the right fit
For everyday CSS — component styles, a theme file, a stylesheet exported from a design tool — stripping whitespace and comments is safe and gets you most of the file-size win a full minifier would, since whitespace and comments are usually the bulk of what compresses away in typical CSS. It's also genuinely useful for the reverse direction: turning an unreadable, single-line minified file back into something you can actually read and edit.
When to reach for something more robust
Real CSS minifiers (csso, cssnano, Lightning CSS) do things this text-transform approach doesn't: merging duplicate selectors, removing genuinely unused rules, shortening color values, and safely handling edge cases inside string literals because they actually parse the CSS instead of pattern-matching characters. If you're optimizing a large production bundle as part of a build pipeline, those tools — usually already wired into Webpack, Vite, or your bundler of choice — will do a more thorough and safer job than a quick paste-and-transform tool.
Common uses
- Quickly compressing a small stylesheet or "above the fold" CSS block before pasting it into a project
- Reformatting a minified third-party or CDN stylesheet into something readable for debugging
- A fast, no-install way to eyeball what minified output looks like before wiring up a real build-tool minifier
FAQ
Will minifying break my CSS?
For typical, well-formed CSS, no — it only touches whitespace, comments, and spacing around punctuation. The one edge case worth watching is a string value (like a content property) that itself contains {, }, or ; — a text-based transform can mishandle that in a way a real CSS parser wouldn't, so it's worth a quick diff on unusual files.
Does it support modern CSS syntax like container queries or var()?
It doesn't need to "support" specific syntax, because it isn't parsing property names or values at all — it only acts on whitespace, comments, and a handful of punctuation characters, so it passes through modern syntax it doesn't specifically recognize.
Is there a file size limit?
No hard limit — processing is regex-based text transformation, so it stays fast even on large files, limited only by your device's memory.
Is my code sent to a server?
No. All processing happens in your browser's memory. Your CSS is never uploaded anywhere.