CSS Minifier

Minify and compress CSS in one place

This CSS minifier shrinks your stylesheets by removing every character the browser doesn't need — comments, whitespace, line breaks and the redundant final semicolon in each rule — so the file you ship is byte-for-byte smaller but renders identically. Paste your code or drop in a .css file and the compressed result appears instantly, with the exact bytes and percentage you saved.

It's also a CSS compressor and a CSS beautifier in one: a single toggle flips between minifying and un-minifying, so the same tool that crunches a stylesheet down can also expand a minified one back into readable, indented code.

What it removes — and what it never touches

When you minify CSS, the tool strips comments, collapses all whitespace, removes the spaces around symbols like { } : ; , > +, and drops the last semicolon before each closing brace. Turn on Aggressive mode and it also removes leading zeros (0.5em → .5em) and the unit on zero-length values (0px → 0).

Crucially, it's lossless. Quoted strings, url() values and calc() expressions are protected before anything is stripped, so a value like calc(100% - 2rem) keeps its required spaces and a background image path is never mangled. Many quick online minifiers get calc() wrong — this one doesn't.

Minify or beautify — a true two-way tool

Need to read a stylesheet that's been squashed onto one line? Switch to Beautify mode to unminify CSS: the tool re-indents the code, puts each declaration on its own line, adds a space after every colon and lays selector lists out cleanly. Choose 2-space, 4-space or tab indentation to match your project's style.

Because minifying and beautifying are reversible, you can paste minified production CSS, read it, tweak it, and minify it again — all without leaving the page.

How this compares to cssminifier.com, CleanCSS and cssnano

cssminifier.com is the most-used online option, but it uploads your code to their server. For proprietary stylesheets — client projects, unreleased designs, internal tooling — that's a real risk. CleanCSS and cssnano are Node.js libraries: great for automated pipelines but unavailable without a local install. freeformatter.com's CSS minifier and TopTal's CSS minifier are both server-side too.

This tool processes everything locally with JavaScript — nothing is uploaded, ever. It covers the most common minification optimisations (whitespace, comments, semicolons, zero-units, leading zeros) and adds a gzip estimate in the same step. No account, no upload, no install — works on iPhone, Android, Mac, Windows and Linux.

See the bytes you save — including gzip

A prominent stats bar reports the original size, the output size, and the bytes and percentage saved, so you always know exactly how much smaller your CSS got. Sizes are measured in real UTF-8 bytes, not character counts, so they match what your server actually serves.

It also shows a gzipped figure computed locally in your browser. Minification and gzip stack — minify the source, then let your host compress it — and seeing both numbers makes the combined saving obvious. That's the 'and compressor' angle, quantified.

100% private — nothing leaves your browser

Every minify and beautify runs locally in your browser using JavaScript. Your CSS is never uploaded, logged or stored, which makes this a safe place to compress proprietary, unreleased or client stylesheets. There's no sign-up and no limit beyond your device's memory. It works offline too — once the page has loaded, disconnect your internet and the minifier still runs. Bookmark this online CSS minifier and reach for it whenever you need to compress CSS, shrink a file, or read a minified one.

The specific transformations minification performs

CSS minification is not a single operation — it's a pipeline of targeted transformations, each shaving bytes in a different way. At the most basic level, all whitespace (spaces, tabs, newlines) between tokens is collapsed to nothing, and every /* comment */ block is dropped. Less obvious but equally valuable: the trailing semicolon in each declaration block is redundant (CSS parsers don't need it before a closing brace), so color: red; becomes color: red — one byte per rule. Spaces around structural characters like { } : ; , > + ~ are removed entirely.

More advanced passes attack the values themselves. Zero-unit removal converts 0px, 0em, 0%, and any other zero-length value to bare 0, because the unit is meaningless when the number is zero. Leading-zero removal shortens 0.75rem to .75rem. Color shorthand converts six-digit hex colors with repeating pairs — #ffffff becomes #fff, #112233 becomes #123 — and named colors like white may be converted to their shorter hex equivalents. Shorthand property merging collapses four separate margin or padding declarations into a single shorthand: margin: 10px 0 10px 0 becomes margin: 10px 0. Together these passes routinely reduce a real stylesheet by 15–30% before any network compression touches it.

Redundant selector consolidation is another optimisation some minifiers apply: duplicate rules targeting the same selector are merged, and selector lists that appear multiple times in the file may be de-duplicated. Not all minifiers do this — it requires building an in-memory model of the stylesheet rather than a single forward pass — but tools like cssnano include it as an optional advanced transform. Understanding which transforms your minifier applies is important: aggressive optimisations are almost always safe for property values, but selector or at-rule merging can theoretically change cascade behaviour if specificity order matters in edge cases.

CSS is render-blocking — why file size directly affects paint time

By default, every external stylesheet is render-blocking: the browser will not paint a single pixel of the page until it has downloaded, parsed and applied every CSS file in the <head>. This makes CSS uniquely sensitive to file size in a way that most other resources are not. A 200 KB JavaScript bundle can be deferred; a large stylesheet cannot be, without careful engineering. Every kilobyte of CSS shaved off through minification directly shortens the window between the browser's first network request and the moment it can render content — a metric Google's Core Web Vitals measure directly as Largest Contentful Paint (LCP).

To put real-world numbers to this: Bootstrap 4's stylesheet ships at roughly 187 KB unminified. The official minified distribution is around 147 KB — a 40 KB reduction from whitespace and comment removal alone. Once a CDN applies Brotli compression, that drops further to approximately 22 KB delivered over the wire. That's an 88% reduction from the original source size. For a framework stylesheet you can't tree-shake, minification plus server compression is the most impactful optimisation available. For a hand-written stylesheet on a 3G connection, the same stack can move LCP by hundreds of milliseconds — a difference Google's PageSpeed scoring registers directly.

HTTP/2 and HTTP/3 multiplexing reduced the penalty for making many small requests, which changed the calculus for request count optimisations. But multiplexing has no effect on parse time: once bytes arrive, the browser's CSS parser must still walk every character in the file. A smaller file parses faster on every device, including low-end Android phones with slow JavaScript engines. Time to First Byte (TTFB) measures server latency; render-blocking time is about what happens after the bytes arrive. Minification attacks that second window, which TTFB optimisations (CDN placement, edge caching) cannot touch.

Minification vs. bundling vs. tree-shaking: three different tools for three different problems

Minification removes redundant characters from CSS you are already shipping. It makes the file smaller without changing which selectors are present. It's the last step in a build pipeline: you run it on the final output, not on intermediate files. Minification can't remove a selector you don't need — it has no idea which selectors your HTML actually uses.

Bundling solves a different problem: it concatenates multiple CSS files into one, reducing the number of HTTP requests. Before HTTP/2, each additional stylesheet meant an extra TCP round-trip; bundling eliminated that overhead. Under HTTP/2 multiplexing, bundling matters less for request latency but still reduces header overhead and can improve cache efficiency if your whole CSS is in one versioned file. Bundling does not make individual rules smaller — it just merges files.

Tree-shaking (or PurgeCSS, the CSS equivalent) is where the biggest savings live when you use a CSS framework. Bootstrap, Tailwind CSS, and Bulma ship thousands of selectors covering every component and utility combination. Your actual project uses perhaps 5–15% of them. Tree-shaking scans your HTML, JavaScript, and template files for class names and selectors that are actually referenced, then strips everything else from the CSS output. A Tailwind project with all utilities enabled starts at over 3 MB of CSS; after tree-shaking it typically reaches 5–30 KB — before minification. These three techniques are complementary steps in a build pipeline, not alternatives: tree-shake first to remove unused rules, bundle to merge files, then minify the result. All three together produce the smallest possible stylesheet.

Professional CSS minification tools — and when to use each

cssnano is the industry standard for automated pipelines. It's a PostCSS plugin, so it integrates directly into any PostCSS workflow and by extension into Vite, webpack, and Parcel, which all have PostCSS support built in. cssnano runs a configurable set of transforms — from safe defaults like whitespace removal to advanced passes like shorthand merging — and produces source maps so DevTools can still show you original source lines. CleanCSS is an older but still widely used Node.js alternative; it's fast and ships with a web interface at cleancss.com for ad-hoc use. For teams already using PostCSS in their pipeline, cssnano is the default choice; for projects without PostCSS, CleanCSS works well as a standalone tool.

LightningCSS (formerly Parcel CSS) is a Rust-based CSS parser, transformer, and minifier that benchmarks at roughly 100× faster than JavaScript-based tools on large stylesheets. It handles minification, vendor prefix lowering, and future CSS syntax transforms in a single pass. Vite 4.4+ ships LightningCSS as an opt-in minifier alongside its default esbuild CSS processing. esbuild's built-in CSS bundler and minifier is also written in Go and dramatically faster than Node.js tools, though it handles fewer advanced transforms than cssnano. For large design systems or monorepos where CSS build times are measurable, LightningCSS or esbuild are worth evaluating.

A manual online minifier like this tool fills the gap that build tools can't: stylesheets that exist outside your build pipeline. WordPress theme CSS edited in the Customizer, a <style> block inside an HTML email, a one-off stylesheet for a static page, a snippet pasted from a tutorial — none of these pass through Vite or webpack. For those cases, pasting into a browser-based minifier is faster than wiring up a build tool. The practical rule of thumb: use a build tool (cssnano, LightningCSS, esbuild) for anything in version control with a build step; use a manual minifier for everything else.

Why minification still matters when your server gzips everything

A common misconception is that server-side compression (Gzip or Brotli) makes CSS minification redundant. It doesn't — the two techniques attack different problems and compound rather than compete. Gzip and Brotli work by finding repeated byte sequences across the entire file and replacing them with back-references. The more uniform and repetitive the content, the better compression ratios they achieve. Minified CSS, with its shorter property names, merged shorthands, and eliminated whitespace variety, produces fewer unique token sequences. Sending minified CSS through Brotli typically yields a 3–8% better compression ratio than sending the formatted original through Brotli — a free gain from doing both steps.

The second reason minification matters independently of compression is that not all bytes are compressed. A client ignoring the Content-Encoding header, a proxy that strips encoding, a CDN misconfiguration, or a service worker cache that stored an uncompressed copy will serve the raw bytes. Minified raw bytes are always smaller than formatted raw bytes. There's also parse time: decompression happens at the network layer before the CSS parser sees the bytes, so the parser always works with the decompressed file. A smaller decompressed file — i.e., a minified one — means a faster parse regardless of what happened over the wire. Minification and compression belong together in every production workflow, not as an either-or choice.