CSS minification typically reduces file size by 20-40%. Files with many comments, long property names, or generous whitespace see the highest reductions.

Is minified CSS safe to use in production?

Yes, completely. Minifying CSS only removes characters that browsers ignore anyway — whitespace, comments, and redundant separators. The actual CSS rules are identical.

Should I minify CSS manually or use a build tool?

For production projects, use a build tool like webpack, Vite, or Parcel that minifies CSS automatically during the build process. Use this tool for quick one-off minification or testing.

What is the difference between CSS minification and compression?

Minification removes unnecessary characters from source code. Compression (like gzip or Brotli) compresses the resulting bytes further at the HTTP level. Both together produce the smallest possible file transfer size.

About CSS Minifier

You shipped a marketing landing page with 40KB of unminified CSS and Lighthouse just dropped your LCP score from 91 to 78 because the render-blocking stylesheet now costs 280ms to parse on a throttled 3G connection. Or your email template build pipeline does not include PostCSS and you need to inline a 12KB style block under Gmail's 102KB total message cap. Paste the raw CSS, hit minify, and every comment, run of whitespace, redundant zero unit (0px → 0), and trailing semicolon before a closing brace gets stripped. Typical output is 30-50% smaller than the input. The tool also handles the single-line JavaScript case (strip comments and collapse whitespace for a quick inline script), which is useful for critical-path inline scripts in server-rendered pages. Output is ready to paste into a <style> tag, a Tailwind @layer block, or a Next.js globals.css file.

How it works

1
Comment and whitespace stripping via regex passes
First pass removes /* ... */ comments including multi-line ones. Second pass collapses runs of whitespace (tabs, newlines, multiple spaces) to single spaces, then removes the spaces adjacent to syntax characters {, }, :, ;, and , where they are never needed. This preserves whitespace inside string literals like content: ' spaces ' by regex-aware parsing.
2
Redundant-token elimination
The minifier strips the last ; before a } (optional per the CSS spec), converts 0px / 0em / 0% / 0rem to bare 0 in places where units are dimensionless by spec, and leaves color shortening (e.g. #ffffff → #fff) to dedicated optimizers like csso since it requires deeper parsing to avoid breaking named-color edge cases.
3
JS mode does a conservative whitespace collapse
Switch to JS mode for a quick single-file script minify. It strips // line comments and /* */ block comments, then collapses whitespace outside string literals. It is not a full minifier like terser — no variable renaming, no dead code elimination — so use it for inline critical scripts, not for your main bundle.

Pro tips

Minify after autoprefixing, not before

If you run autoprefixer or a PostCSS plugin chain on minified input, many of them silently add extra whitespace back or produce broken output because they rely on formatting cues to parse. Always keep minification as the final step in your pipeline: source → autoprefixer → cssnano → done. If you are doing this manually, paste the autoprefixed output here, then minify, then ship. The source-map cost of one extra step is minor compared to the size win.

Watch for custom property values that break on collapse

A custom property defined as --gradient: linear-gradient( 135deg, #000 0%, #fff 100% ) is parsed as-is — the whitespace inside matters for how browsers report the computed value via getComputedStyle. Most minifiers including this one preserve it correctly, but if your test suite diffs computed styles between minified and source builds, pin --gradient values in a CSS variable at the :root level so the raw whitespace pattern does not drift.

Check gzip size, not raw size

Raw minification cuts bytes but gzip or brotli on the server does most of the actual work. A 40KB CSS file often compresses to 6KB over the wire; minification before gzip usually saves another 1-2KB. If your bundler already handles compression, the real win from minifying is parse time on the client (roughly 1ms per KB of CSS on mid-tier phones), not transfer time. Measure with Chrome devtools' Coverage panel to see actual runtime cost.

Honest limitations

· No CSS variable resolution or tree-shaking of unused selectors — use PurgeCSS or the built-in Tailwind JIT for that level of optimization.
· Does not validate CSS syntax — a missing closing brace will produce broken output, not an error. Validate with the W3C CSS validator first.
· JS mode is a whitespace-only minifier; it cannot rename variables or eliminate dead code. Use terser or esbuild for production JavaScript bundles.

Frequently asked questions

How much size reduction should I expect?

For hand-written CSS with typical formatting (80-character lines, 2-space indent, one property per line, comments), expect 30-50% size reduction. For CSS already built by a preprocessor like Sass or PostCSS in expanded output mode, expect 20-35%. For CSS that is already compressed by a CLI tool like cssnano or clean-css, our output will be roughly equivalent — we do not do advanced optimizations like merging adjacent selectors or shortening longhand properties to shorthand form. The biggest win is comment removal; documentation-heavy CSS can shrink by 60% or more.

Will minifying break my CSS custom properties or container queries?

No. The regex-based parser is whitespace-aware for the syntax characters but preserves the content of values exactly, which is what matters for --vars, calc() expressions, and @container or @supports conditions. The only edge case is if you have intentional newlines inside a value (most CSS values cannot have them anyway per the spec). If you see unexpected behavior after minification, paste both the input and output into a diff tool and check whether a custom property value changed — 99% of the time the real culprit is a typo that predates the minification step.

Can I use this for SCSS or Less files?

No, not directly. SCSS and Less have syntax (nested selectors, @import of partials, variables with $ or @ prefix, mixins, functions) that is not valid CSS and will produce broken output if minified before compilation. Compile your SCSS to CSS first using the Sass CLI or a PostCSS plugin, then paste the compiled CSS here for minification. If you want CSS-in-JS output minified, use the css-minifier output of your bundler (Vite and Next.js minify in production builds automatically).

Is there a difference between 'production mode' and 'development mode' minification?

Not in this tool — output is always fully minified with no source map. In a proper build pipeline, development mode typically leaves CSS readable for debugging (with source maps pointing back to the original files) and only minifies in production. If you are copying minified output into a dev environment for testing, keep a copy of the source so you can re-minify after every change. For production deployment, integrate the minification into your CI/CD so the minified-vs-source gap cannot drift.

Does the tool preserve @font-face src URLs with query strings?

Yes. The minifier does not touch the contents of string literals or url() values. A declaration like src: url('/fonts/Inter.woff2?v=2') format('woff2') will survive minification with the query string and the single-space between url() and format() intact (that space is required by the spec). The same applies to data URIs, background-image gradients with embedded color stops, and any url-encoded content. The only whitespace that gets collapsed is between CSS tokens, never inside a value.

Minified CSS usually ships alongside minified JSON config and inline scripts, so pair this with the json-formatter's minify mode when preparing a single-file HTML bundle for email or embeds. If you are inlining a base64-encoded font or SVG inside the CSS to avoid an extra request, the base64-encoder handles that conversion. And for matching selector patterns in a refactor (finding every usage of .btn-primary across a codebase), the regex-tester is how you build the find-and-replace pattern that a bare Ctrl+F cannot handle.