CSS Minifier - Compress CSS Online, See Bytes Saved

What minification actually removes

Browsers ignore almost all whitespace in CSS. They do not care whether a rule is on one line or twelve, whether you indent with two spaces or a tab, or whether the last declaration ends with a semicolon. Minification deletes all of that, plus comments, and leaves the exact same instructions in fewer bytes.

This tool runs six steps in order: set aside quoted strings, strip /* comments */, collapse every run of whitespace to one space, remove spaces around { } ; , > and ~, remove the space after a colon, and drop the semicolon right before a closing brace. Then the strings go back in untouched.

The three places naive minifiers break CSS

Strings. content: "a ; b" or font-family: "Open Sans" must keep their inner spaces and semicolons. A regex that squeezes every semicolon will corrupt them. Protecting strings first avoids that.

The space before a colon. In a selector, .nav :hover means "any hovered element inside .nav" and .nav:hover means ".nav itself when hovered". Collapsing that space changes which elements get styled. This tool only removes the space after a colon, which is always safe.

Math. calc(100% - 2rem) is valid; calc(100%-2rem) is not, because the spec requires spaces around + and - inside calc(). That is why + is not in the list of characters that get their surrounding spaces stripped. The same goes for media query keywords: "screen and (max-width: 600px)" needs the space before the parenthesis.

Worked example

The sample stylesheet in the tool is a card component with a comment, a grouped selector, a font stack, a calc() width, an !important color, and a media query. It is 241 bytes as written with normal indentation. Minified it comes out at 182 bytes, a 24% cut, and every rule does the same thing.

Scale that to a real stylesheet. A 60 KB hand-written CSS file usually drops to 45-50 KB. After Brotli compression on the server, the difference in transfer size is closer to 2-4 KB, because compression already handles repeated whitespace well. Minification still helps: it reduces parse work and makes the compressed file a little smaller too.

Where minified CSS matters for rankings

CSS is render-blocking. The browser will not paint the page until it has downloaded and parsed the stylesheets in the head, so every kilobyte there sits directly on the path to First Contentful Paint and Largest Contentful Paint. Google uses LCP as a Core Web Vitals signal, and PageSpeed Insights lists "Minify CSS" as a named opportunity.

The bigger win is usually removing unused CSS, not minifying used CSS. If you ship a full framework and use 10% of it, minification shaves maybe a quarter off, while purging unused selectors can cut 80-90%. Do both: purge first, then minify.

Common mistakes

Editing the minified file. Always keep the readable source and regenerate the .min.css from it. Minified CSS is an output, not something you maintain.

Minifying twice in a pipeline. Harmless, but if your framework already minifies on build, running a second minifier adds build time for zero bytes.

Forgetting cache busting. If you replace styles.css with a minified version under the same URL, returning visitors may keep the old cached copy. Change the filename (styles.min.css or a content hash) when you deploy.

When to use a build tool instead

For a site with a build step, use the minifier that ships with it: Vite and esbuild minify CSS in production mode, Lightning CSS and cssnano go further by merging duplicate rules, shortening colors (#ffffff to #fff), and dropping zero units. This page is for the jobs outside a pipeline: a snippet for WordPress Additional CSS, a Shopify theme edit, an HTML email, or a quick check of how much a file would shrink before you set up tooling.