CSS Minifier — strip the slack from your stylesheets
Paste a CSS stylesheet and get a minified version with comments, redundant whitespace and trailing semicolons removed. Live byte stats and one-click copy.
Paste a CSS stylesheet and get a minified version with comments, redundant whitespace and trailing semicolons removed. Live byte stats and one-click copy.
.header{background-color:#fff;color:#333;padding:16px 24px;margin:0}.btn{display:inline-block;padding:8px 16px;border-radius:4px;background:#0ea5e9;color:#fff;transition:background 0.2s ease-in-out}.btn:hover{background:#0284c7}A typical hand-written CSS file carries 20-40% of its bytes in comments, indentation, and the last semicolon of every rule. Minifying removes all of that without changing the rendered output, shrinking the file your users have to download. The savings compound across the network, the parser, and the cache.
This tool runs the minification entirely in your browser using a lightweight regex-based pass: comments stripped (except /*! license blocks), whitespace collapsed, redundant punctuation removed, simple optimisations like '0px → 0' and 6-digit hex colours shortened to 3-digit when possible. The output is functionally identical to the input.
Yes. The minifier only removes characters that don't affect parsing or rendering. The cascade, specificity and computed values stay identical. Test in your staging environment before swapping production CSS, but the changes are mechanical.
Yes — comments starting with /*! are kept verbatim. That's the convention many bundlers (esbuild, Terser, csswring) use to mark license headers and other comments that must survive minification.
The tool runs in your browser; on a modern laptop, files up to ~1 MB process in well under a second. Bigger stylesheets work but the textarea may get sluggish — at that point you should be running the minifier as part of a build pipeline, not pasting into a web tool.
This tool does not emit source maps. If you need to debug minified CSS in production, generate maps with your build tool (esbuild --sourcemap, postcss with postcss-sourcemaps, etc.) instead.
If your CSS was already auto-formatted by Prettier or your editor, much of the 'wasted' whitespace is single newlines and double spaces — far less savings than a verbose hand-formatted file. Minifying is still worthwhile but the percentage is lower.
Where minifying CSS is a quick, free win.
When inlining a few KB of critical CSS into a <style> tag in <head>, minify it first. Every byte counts above the fold; an unminified CSS block can dwarf the actual HTML.
Hugo, Jekyll, Eleventy and other static generators don't minify by default. Run the output through this tool before publishing to shave 20-30% off your CSS payload with no toolchain changes.
When comparing two CSS files diff-by-diff, minifying both first removes whitespace noise and surfaces the real semantic difference between them.
Email clients have stricter size limits than browsers. Gmail famously clips emails over ~102 KB. Minifying inline CSS gives you breathing room before the clip kicks in.
Habits that keep CSS lean from authoring through deployment.
Server-side compression already shrinks repeated whitespace efficiently — minified CSS is mostly about reducing parser work and edge-cache size, not raw transfer. Both still help; minify regardless.
Author readable CSS. Run the minifier as a build step or just before deployment. Editing minified CSS by hand is a path to subtle bugs that don't surface until production.
Some old hacks rely on extra whitespace or specific selector forms — IE-targeted *html, * + html, etc. Modern minifiers (this one included) preserve them, but verify if your target audience still includes legacy browsers.
Minification doesn't fix specificity wars. If you're frustrated with !important chains, the cure isn't tighter minification — it's restructuring your CSS to use cascade layers or scoped selectors instead.