Minify your CSS file to a smaller .css output by stripping unnecessary characters while preserving how your styles render.
.css file directly onto the editor. The tool accepts any valid CSS — a handful of rules or a full production stylesheet several megabytes in size.}, and shorten zero values (0px → 0) and hex colors (#ffffff → #fff). Toggle "preserve /*! comments" if your stylesheet ships with a license banner. Vendor prefixes (-webkit-, -moz-) are kept intact — manage those with Autoprefixer, not a minifier..min.css. Output is production-ready — drop it into your CDN, your <style> tag, or your build pipeline.CSS minification strips characters that browsers ignore — whitespace, comments, trailing semicolons, redundant units — without changing how the page renders. Typical reductions land in the 15-25% range for already-tidy code and 30-50% for heavily commented, well-indented source files. Combined with gzip or Brotli, the same CSS often ships at 5-10% of its original byte count.
| Technique | Example before | Example after | Risk |
|---|---|---|---|
| Whitespace removal | body { color: red; } |
body{color:red} |
Zero |
| Comment stripping | /* hero block */ |
(gone) | Zero (preserves /*!) |
Trailing ; before } |
color: red; |
color:red |
Zero |
| Zero-unit shortening | margin: 0px |
margin:0 |
Zero |
| Hex shortening | #ffffff, #ff0000 |
#fff, red |
Zero |
Quote removal in url() |
url("img.png") |
url(img.png) |
Zero if no special chars |
| Longhand → shorthand | margin-top:1px;margin-right:1px;… |
margin:1px |
Zero if all four sides set |
| Rule merging (advanced) | .a{color:red}.b{color:red} |
.a,.b{color:red} |
Can shift specificity order |
| Property reordering (advanced) | declarations resorted | resorted | Can break cascade if rules duplicate |
The conservative defaults — first seven rows — are safe on any valid CSS. Advanced rule merging and property reordering (the optimizations cssnano and csso apply at their highest levels) can change cascade order and should be smoke-tested in a staging environment before shipping.
| Tool | Language | Typical compression (Bootstrap 5) | Notes |
|---|---|---|---|
| clean-css (level 2) | JavaScript | ~79.7% of original | Widely used, configurable, source-map support |
| cssnano (advanced) | JavaScript (PostCSS) | ~78.6% | Plugin ecosystem; default in css-minimizer-webpack-plugin |
| csso | JavaScript | ~78.6% | Restructures selectors aggressively |
| Lightning CSS | Rust (compiled to native + WASM) | ~78.3% | ~100× faster than JS tools; default minifier in Vite 8+ |
| esbuild | Go | Comparable to Lightning CSS | Fast; pairs with esbuild JS pipeline |
| XConvert CSS Minifier | Browser (this page) | Comparable to clean-css level 1 | Zero install, no server, no upload |
Compression numbers above are from the goalsmashers css-minification-benchmark — they're remarkably close across mature tools because the dominant savings come from whitespace and comments, which all minifiers handle equivalently. Tool choice usually comes down to build-pipeline fit, not output size.
For well-formatted source CSS with comments and indentation, expect 15-40% reduction. Bootstrap 5 unminified is about 205 KB; minified it's around 161 KB (78.6%) per the public benchmark. Reductions below 10% mean the input is already compact (likely already minified, or written without indentation); reductions above 60% usually mean large comment blocks or duplicated rules — worth a manual review. After gzip/Brotli, the wire-bytes savings stack: minify first, compress second.
Whitespace, comment, and trailing-semicolon removal is safe on any valid CSS — the resulting bytes parse identically. The risky transforms live in "advanced" or "level 2" modes: merging duplicate selectors, reordering properties, hoisting @media rules. These can change cascade order if your stylesheet has duplicate selectors that depend on source order, or if a later rule was intentionally overriding an earlier one. The XConvert minifier sticks to safe transformations by default. If you enable aggressive options elsewhere (cssnano preset: 'advanced', csso with restructure on), run a visual diff against staging before shipping.
If you ever debug live rendering issues in DevTools, yes. A source map (styles.css.map referenced by /*# sourceMappingURL=styles.css.map */) lets Chrome and Edge DevTools show you the original selectors, line numbers, and comments when you inspect a minified element. Best practice in 2026: ship the .map file but serve it only to authenticated requests or your own IPs, so end users see fast minified CSS while you keep debuggability. cssnano, clean-css, Lightning CSS, esbuild, and Webpack's css-minimizer-webpack-plugin all generate source maps with a single flag.
Yes — and the savings dwarf minification. Purging removes entire unused selectors based on a scan of your HTML/JSX templates. On a typical site, 60-90% of shipped CSS rules are never matched. Tailwind CSS does this automatically in production builds (NODE_ENV=production) using its JIT engine; PurgeCSS does it standalone for any framework. Order matters: purge first, then minify, then gzip. Each step compounds: a Tailwind starter that ships 3 MB of utility CSS unpurged becomes ~10 KB after purge + minify, then ~3 KB over Brotli.
Yes, by default. Webpack's css-minimizer-webpack-plugin (cssnano under the hood) runs in mode: 'production'. Vite 8+ uses Lightning CSS for CSS minification by default (older Vite versions used esbuild). Parcel uses Lightning CSS natively — it's developed by the Parcel team. Next.js, Nuxt, Astro, and SvelteKit inherit minification from their underlying bundler. This online tool is most useful when you're outside a bundler context: a hand-written CSS file for a static site, a WordPress child theme, an email template, an embed snippet, or a single utility file you're shipping to a CDN.
Lightning CSS is written in Rust and compiled to a native binary (or WebAssembly for browsers); cssnano runs on the JavaScript event loop through PostCSS. Per the official Lightning CSS benchmarks, it minifies Bootstrap 4 in 4.16 ms versus 544.81 ms for cssnano on the same machine — about 130× faster. For a single small stylesheet that gap is invisible. For a monorepo with hundreds of CSS files being rebuilt on every save, it's the difference between an HMR cycle under 100 ms and one over 5 s. Output size is comparable; the win is build-time latency.
No — preprocessors must compile to CSS first. SCSS variables, @mixin, @extend, nesting, and & parent selectors are not valid CSS and won't parse here. Run sass, lessc, or stylus on your source, then paste the compiled CSS output into the minifier. Modern CSS supports native nesting and custom properties, so for new projects you can often skip the preprocessor entirely.
Runtime CSS-in-JS libraries (styled-components, Emotion runtime) generate styles dynamically in the browser, so there's no static file to minify here. Build-time CSS-in-JS libraries (vanilla-extract, Linaria, Compiled, Pigment CSS) emit a static .css file as part of the build — that file can be minified by your bundler or pasted into this tool. The CSS-in-JS library itself does not minify; that's the bundler's job downstream.
No. The parser runs as JavaScript inside your browser tab — your CSS is never sent to xconvert.com or any third party. You can confirm this by opening DevTools' Network panel, hitting Minify, and seeing zero outbound requests. This matters when your CSS includes unreleased design tokens, internal class names, or feature-flag selectors you'd rather not surface in someone else's server logs.
When you're done minifying, the inverse operation lives at CSS Formatter — paste minified CSS back in to restore readable indentation for debugging. For full-page optimization, see the HTML Minifier and JS Minifier, and for inspecting embedded JSON config in your stylesheets the JSON Formatter is a couple of clicks away.