CSS Minifier

A CSS minifier removes whitespace, comments, and redundant characters from CSS code to reduce file size and improve page load performance. It is used by front-end developers, performance engineers, and web designers who want to ship production CSS that loads as quickly as possible.

How to Use the CSS Minifier

1. Paste your formatted CSS code into the input field.
2. Click the minify button.
3. The tool outputs the minified CSS with all unnecessary characters removed.
4. Check the size reduction percentage shown alongside the output.
5. Copy the minified CSS and replace your development file, or include the output in your build pipeline.

The Formula

CSS minification applies a sequence of conversions to reduce file size without changing how the browser renders the styles:

1. Remove all comments (text between /* and */).
2. Remove all whitespace that is not required by CSS syntax, including leading and trailing spaces, newlines, and tabs.
3. Collapse multiple spaces into a single space where a space is syntactically required (for example, between a property and value).
4. Remove the final semicolon in each declaration block (the last semicolon before a closing brace is optional in CSS).
5. Remove unnecessary zeros (e.g., 0.5 becomes .5, 0px becomes 0).
6. Shorten colour values where possible (e.g., #ffffff becomes #fff, rgb(255,0,0) becomes red).
7. Collapse shorthand properties and remove redundant declarations where applicable.

The result is functionally identical CSS that a browser parses and renders exactly as the original, but in significantly fewer bytes.

Real-World Example

You have a 12KB CSS file for your web application. After minification, the output is 7.2KB, a 40% reduction. On a slow mobile connection of 1Mbps, this saves approximately 38 milliseconds of download time per page load. For a site with 50,000 monthly visitors, this represents millions of milliseconds of cumulative load time saved. When combined with gzip or Brotli compression (which most web servers apply automatically), minified CSS can compress to 1 to 2KB, an even more significant gain.

CSS Minification in Build Pipelines

In modern web development, CSS minification is almost never done manually. Build tools such as Vite, Webpack, Parcel, and esbuild minify CSS automatically as part of the production build step. PostCSS with the cssnano plugin is a popular standalone option. These tools can also perform more advanced optimisations such as removing unused CSS selectors (tree-shaking), autoprefixing for browser compatibility, and merging duplicate rules. For small projects without a build pipeline, an online CSS minifier provides the same benefit with no setup required.

Frequently Asked Questions

Will minification break my CSS? Minification should never change how your CSS renders if it is done correctly. It only removes characters that carry no semantic meaning. However, some aggressive optimisers may merge or reorder rules in ways that affect specificity. Always test your minified output in a browser before deploying to production.

Should I serve minified CSS or the original file? Always serve minified CSS in production. Keep your original formatted file for development and let your build process generate the minified version automatically. Never manually edit the minified file; edit the source and re-minify.

What is the difference between minification and compression? Minification removes unnecessary characters from the source code itself. Compression (gzip or Brotli) is applied by the web server to the file during transmission, further reducing its size for the browser download. Both should be applied: minify first, then serve with compression enabled.

How much size reduction should I expect? Typical CSS minification reduces file size by 15 to 40%, depending on how much whitespace and how many comments the original file contains. When combined with gzip compression, total size reduction of 70 to 85% compared to the original formatted file is common.

A byte level minification of one stylesheet

Percentage reductions are hard to sanity check. Byte counts are not. Take this stylesheet, which is a realistic small component file with a comment, indentation and a few longhand values:

/* Card component */
.card {
    padding: 16px 24px;
    background-color: #ffffff;
    border-radius: 0.50em;
    margin: 0px auto;
    color: rgb(255, 0, 0);
}

.card:last-child {
    margin-bottom: 0px;
}

The file is 208 bytes. Minified, it becomes one line:

.card{padding:16px 24px;background-color:#fff;border-radius:.5em;margin:0 auto;color:red}.card:last-child{margin-bottom:0}

That is 122 bytes. The saving is 86 bytes, or 41.3 percent.

Which rule paid for which byte

Splitting the 86 bytes by the rule that produced them shows how much of the gain comes from the boring part of the job.

Whitespace and newlines contribute 46 of the 86 bytes, more than half. The colour and number rewrites contribute 20 between them. A file with no comments and no longhand colours would save less than 30 percent, because there would be little left to remove. A file with a license header and paragraph comments can save well over half. That spread is why published reduction figures for CSS minification are quoted as a range and not a number.

Note what did not change. Every selector, every property and every value is the same CSS. The browser parses the minified file into the same rule set as the original. Minification removes characters; it does not rewrite logic.

Where whitespace carries meaning, and must be left alone

A naive minifier that strips every space will break a stylesheet. Six places in CSS give whitespace a job.

The crontab-style rule for the first row comes from the CSS Values and Units specification: whitespace is required on both sides of the + and - operators inside calc(), and is optional around * and /. Minifiers that rewrite newlines without preserving a space hit this exact case, and the result is a declaration the browser discards. If you hand-minify a file that uses calc() with addition or subtraction, check those lines first.

What compression adds on top

Minification and gzip operate on different things. Minification shrinks the file on disk. Compression shrinks it on the wire. Two files, both valid, in both states:

Gzip takes the original from 208 bytes to 166, a 20.2 percent cut, because indentation and repeated property names compress well. It takes the minified file from 122 to 121 bytes, a cut of 0.8 percent, because there is almost nothing repetitive left. Serving the minified file with gzip on gives 121 bytes against 208 for the formatted file, a total reduction of 41.8 percent.

The lesson generalises. Once a file is minified, most of the compression work is already done, so the two steps overlap rather than stack. On the 12 KB file in the example above, minified first and then compressed, the pair reaches the low single-digit kilobyte range because a larger file gives the compressor more repeated structure to find. Compressing the unminified original reaches a higher byte count than compressing the minified version, so the order matters: minify, then compress.

Gzip also carries a fixed overhead of roughly 18 bytes of header plus framing on every response. On a 208 byte file that overhead is visible in the ratio. On a 12 KB file it is noise. That is the other reason small-file measurements of compression look worse than the figures quoted for production bundles.

What the minifier can and cannot do

Minification rewrites text, and that bounds what any minifier can do.

1. It has no view of your HTML, so it cannot remove selectors your templates never use. Unused-CSS removal needs a build step that reads the markup, which is a different job from minification.
2. Licence headers need protecting. A comment that begins with /*! is the convention for a header that must survive, and a minifier that drops it can leave you shipping a library without its terms attached. Check how whichever tool you use treats those comments before you put it in a pipeline.
3. Case must survive. Class names, custom property names and url() values keep their casing, and a minifier that lowercases them breaks a stylesheet on a case sensitive file system even though the output looks harmless.
4. Nothing may be reordered in a way that changes specificity. A minifier that only removes characters cannot change which declaration wins. Optimisers that merge duplicate rules can, and that is a different class of tool.
5. @import targets and font files stay invisible to it, so it will not warn about a stylesheet that pulls in others. Check the import chain separately if you are measuring total payload.

Two numbers from the example above are worth keeping to hand when you size a change. Divide the byte saving by the transfer rate to get the time saved per request: a 4.8 KB saving on a 1 Mibit/s connection is 4.8 multiplied by 1024 multiplied by 8, divided by 1,048,576, which comes to 37.5 milliseconds, the figure the example on this page rounds to 38. Multiply that by request volume to get the aggregate: 38 milliseconds across 50,000 page loads is 1,900,000 milliseconds, or just under 32 minutes of cumulative waiting removed.

A source note on the rewriting rules

The set of transformations a minifier may apply is bounded by the CSS grammar, not by taste. The requirement that + and - keep their surrounding whitespace inside calc() appears in the CSS Values and Units Module Level 3 specification, and the note there is explicit that the two operators need the space while * and / do not. A minifier that respects the grammar can remove every character the grammar marks optional; one that works on whitespace patterns alone cannot be relied on to tell the difference.

Also try these free tools:

• HTML Minifier
• JS Minifier
• JSON Formatter