CSS Minifier
Paste CSS and get a compressed version instantly, comments and extra whitespace stripped, string and url() contents left untouched.
About the CSS Minifier
Shrinking a stylesheet here means stripping /* ... */ comments and squeezing out extra whitespace around selectors, braces, colons, semicolons, and commas. Anything inside url(...) values or quoted strings gets protected first, so file paths and string literals come through intact instead of getting mangled.
It sticks to whitespace and punctuation only, so it won't merge duplicate rules or shorten hex color values, but that also makes it safe to point at production CSS without second-guessing the output.
Why this minifier stops short of "smart" optimizations
More aggressive CSS minifiers go further than whitespace and comments, merging rules with identical selectors, shortening #ffffff to #fff, dropping units from zero values, or reordering properties. Those optimizations save additional bytes, but they carry real risk: merging two rules can silently change which declaration wins under CSS's cascade and specificity rules if the source order mattered, and a handful of edge cases (custom properties, certain calc() expressions) do care about units even on zero. This tool deliberately limits itself to transformations that are always safe regardless of context, whitespace and comments never carry semantic meaning in CSS, so stripping them can never change how a stylesheet actually renders. That safety is the tradeoff against a slightly smaller file than a more aggressive minifier would produce.
Why the size stats use Blob, not the string's character length
The Original Size and Minified Size figures come from new Blob([text]).size, which measures the actual number of UTF-8 bytes the text would occupy, rather than text.length, which counts JavaScript string characters. Those two numbers only match for plain ASCII content. The moment your CSS contains a multi-byte character, an emoji in a comment, a non-Latin character in a generated-content string, a smart quote, .length would undercount the real transfer size, since a single such character can occupy two, three, or four bytes in UTF-8. Measuring with Blob keeps the displayed byte counts and reduction percentage accurate to what actually gets sent over the network, not just how many characters JavaScript thinks the string contains.
Why the reduction percentage never shows a negative number
The reduction calculation is wrapped in Math.max(0, ...), deliberately floored at zero. In the overwhelming majority of cases minifying reduces size, but for extremely small or already-tight input, edge-case rounding could theoretically produce a result at or barely below zero, and displaying "-0.3% reduction" would read as a confusing bug rather than a meaningful number. Flooring at 0% keeps the stat honest and readable without needing to explain a technically-accurate but practically useless negative edge case. It's also worth knowing the ;} to } substitution, dropping the final semicolon right before a closing brace, is one of the few punctuation-only tricks that reliably contributes to that reduction, since a trailing semicolon before a closing brace is always optional and redundant in valid CSS syntax.
A performance reality check: minification's benefit shrinks once gzip is involved
It's worth knowing that most production web servers already apply gzip or Brotli compression to text assets like CSS, and those compression algorithms are extremely effective at squeezing out exactly the kind of repetitive whitespace and formatting this minifier removes. That means the dramatic-looking reduction percentage you see here overstates the real-world savings once your server's compression is factored in, gzip on unminified CSS often gets surprisingly close to gzip on minified CSS in raw transfer bytes. Minification is still worth doing, since minified-then-gzipped is reliably smaller than unminified-then-gzipped, and it also reduces the browser's CSS parsing work independent of network transfer, but it's not accurate to assume the percentage shown here directly translates to that much faster page loading.
Frequently Asked Questions
Why doesn't this minifier merge duplicate CSS rules or shorten hex colors?
Those "smart" optimizations carry real risk, merging rules can change which declaration wins under the cascade if source order mattered, and shortening values can occasionally interact badly with edge cases like custom properties. This tool sticks to whitespace and comment removal, transformations that can never change how a stylesheet renders.
Why does the size comparison use Blob instead of the text's character count?
Blob measures actual UTF-8 byte size, which matches real network transfer size. A plain JavaScript string length count would undercount CSS containing multi-byte characters like emoji or non-Latin text, since those can occupy multiple bytes each in UTF-8.
Can the reduction percentage ever be negative?
No, it's deliberately floored at 0% using Math.max(0, ...). While minifying almost always reduces size, this floor prevents a confusing near-zero or slightly negative result from displaying on extremely small or already-tight input.
Does minifying my CSS make that much of a real difference if my server already uses gzip?
The real-world benefit is smaller than the raw percentage suggests, since gzip and Brotli already compress repetitive whitespace very effectively. Minification is still worthwhile, minified-then-compressed is reliably smaller than unminified-then-compressed, and it also reduces browser parsing work, but don't expect the shown percentage to translate directly into page-load savings.
Will minifying break url() paths or string values in my CSS?
No, url() contents and quoted strings are protected before any whitespace or comment stripping runs, then restored exactly afterward, so file paths, content strings, and any spacing inside them come through unchanged.
Is it safe to run this on production CSS without reviewing the output?
Yes, that's the specific design goal. Because it only removes whitespace and comments, both of which are semantically meaningless in CSS, the minified output is guaranteed to render identically to the original, no visual regressions to check for.