A CSS minifier takes formatted CSS and emits a smaller, equivalent version with all the cosmetic whitespace stripped. The tool above runs the minifier in your browser; nothing leaves your machine. For the inverse direction, see CSS formatter.

What gets stripped

The mechanical reductions a full minifier performs, in roughly the order they happen (the tool above does the first three — see below):

Transformation	Example
Strip comments	`/* comment */` → removed
Strip whitespace between tokens	`color: red;` → `color:red;`
Strip the final `;` before `}`	`color:red;}` → `color:red}`
Shorten 6-char hex to 3-char where possible	`#ffffff` → `#fff`, `#aabbcc` → `#abc`
Lowercase hex	`#FF00FF` → `#f0f`
Strip leading 0 from values	`0.5em` → `.5em`, `0.25` → `.25`
Strip units from zero	`margin: 0px` → `margin: 0`
Collapse same-side margin/padding shorthand	`margin: 10px 10px 10px 10px` → `margin: 10px`
Strip quotes from URL values when safe	`url("file.png")` → `url(file.png)`
Replace `none` with `0 0` in some shorthand	`border: none` → `border: 0` (lossy in edge cases)

Hand-written CSS minifies down 20–40%. CSS already produced by a build tool minifies less because the tool typically already pre-strips comments and whitespace.

What’s not safe to strip

Minifiers have to know syntax to know what’s stripable. The unsafe edges:

Whitespace inside calc(). calc(100% - 10px) requires the spaces around -. calc(100%-10px) is invalid. Naive whitespace stripping breaks this.
Whitespace inside string values. content: "hello world" has a literal space; the minifier must not collapse it.
Comments inside content strings. content: "/* not a comment */" is a string containing the literal characters; the minifier must not strip them.
/*! ... */ “important” comments. Some minifiers preserve comments starting with /*! to keep license banners intact. Plain /* comments are stripped.
@charset directive. Must remain at the very start of the file as the first non-comment content. Some minifiers move or strip it incorrectly.
Selector-specific whitespace. a > b (child combinator) and a b (descendant combinator) and a+b (adjacent sibling) all have whitespace semantics. Stripping carelessly conflates them.

A correct minifier parses the CSS, transforms the AST, and re-emits — not regex-based string manipulation.

The tool above is a whitespace minifier: it removes comments (keeping /*! … */ license comments), the whitespace between tokens and the last ; in each block. It sets string values and url(...) aside first, keeps the spaces inside calc(), and keeps a space before : in selectors like div :hover. It does not shorten colors, drop zeros and units, or merge shorthands — for those, use a parser-based minifier such as cssnano, csso or Lightning CSS in your build.

Lossy vs lossless minification

Most CSS minifications are lossless — the output is functionally identical to the input. Some optimizations are near-lossless — they’re only correct in normal cases:

Collapsing border: none → border: 0 is technically lossy if the rule is overridden by a later border: solid (the result depends on whether border-style is none or default). Some minifiers do this; some don’t.
Removing duplicate selectors and merging declarations is lossy if any of them have side effects in the cascade.
Converting 0.0 to 0 is fine; converting 0.0 to nothing is wrong (empty value is a parse error).

If a minified file behaves differently than the formatted source, suspect lossy optimizations. Most minifiers have an option to disable risky transformations.

Comparison with other size reductions

Reduction	Typical savings	Complementary with minification
Minification	20–40%	—
gzip	80–90% on text	Yes (always also gzip)
Brotli	85–95% on text	Yes (better than gzip when supported)
Removing unused CSS	varies — sometimes 50%+ on bloated codebases	Yes
Splitting critical CSS	shifts bytes off the critical path	Yes

Minification is one layer. Gzip/brotli applied to minified output saves a bit less than applied to formatted output — minification removes some of the redundancy gzip exploits. Net is still positive, but the marginal benefit of minification on the wire is smaller than the disk-savings number suggests.

When minification doesn’t matter

HTTP/3 with brotli at the CDN. The bytes you save by minifying are a small fraction of the bytes already saved by compression.
CSS that’s already auto-generated. Build tools (Tailwind, CSS Modules) often emit pre-minified output.
Development. Source-mapped minification is fine; un-source-mapped minification makes debugging painful. Use the formatted version locally.

When it does matter:

Inline CSS in HTML. Bytes count more here because they’re not separately compressed at the file level.
Sites with large CSS bundles (legacy hand-written or atomic-CSS frameworks). Minification savings compound with bundle size.

Common pitfalls

Re-minifying minified CSS. Some minifiers are idempotent; some have bugs and produce subtly different output on the second pass. Don’t double-minify.
Minifying without source maps. Production debugging gets harder. Always emit source maps even if you don’t ship them publicly.
Stripping vendor prefixes. Some “smart” minifiers detect dead vendor prefixes (-webkit- for properties that no longer need it) and strip them. This can break older browser support — check the targeted browsers before enabling.
Hand-editing minified CSS. It’s not a hand-edit format. Edit the formatted source and re-minify.

For the inverse direction, see CSS formatter. For other minification needs, see HTML minifier and JSON minifier.

CSS Minifier