Skip to content
Reembun
CSS minifier icon
Developer

CSS minifier

Minify or beautify CSS with a parser that never corrupts strings, url() values or calc() expressions.

Ready. Runs locally on your device.

Your files stay on your device. The tool works directly in your browser, using your device to process your files. Nothing is sent to our servers, and we never receive, store, or see your files or figures.

Share

Share this page

Share result

Your results

Use the tool above first. Whatever it works out shows up here, ready to copy or share.

Cite

Cite this page

Reembun. (2026, July 28). CSS minifier. https://reembun.com/css-minifier
Pick a style, then copy the reference. The access date is today.

How to use it

  1. Paste your CSS

    Drop the whole stylesheet in. It is processed in this tab, so unreleased styles stay private.

  2. Read the saving

    The size before and after is shown with the percentage saved, which tells you whether it is worth doing at all.

  3. Copy the output

    Keep your original. Minified CSS is for serving, never for editing, and the comments you removed were probably load bearing.

What it removes

  • Comments, except licence banners beginning /*!
  • Whitespace, collapsed to a single space and dropped where syntactically unnecessary
  • Redundant semicolons, including the last one before a closing brace

What it deliberately does not do

Aggressive minifiers also reorder declarations, merge rules, rewrite shorthand and re-encode colours. Each of those can change behaviour:

  • Reordering declarations breaks the cascade when a longhand follows a shorthand
  • Merging rules changes specificity resolution in edge cases
  • Rewriting shorthand can drop an implicit value that a later rule relied on
  • Re-encoding colours is safe until it meets a colour in a format the tool guessed wrong about

None of those are done here. Everything removed is whitespace, comments or syntactically redundant punctuation.

The cases regex minifiers fail

A regex-based minifier cannot tell whether a { is structure or content. All of these are valid CSS and all break naive tools:

a { content: "/*"; }        /* a comment marker inside a string */
a { content: "}"; }          /* a brace inside a string */
a { content: "a;b"; }        /* a semicolon inside a string */
a { background: url(data:image/svg+xml;base64,AAA); }

This minifier is a character scanner that tracks state, so strings and url() values pass through untouched.

Where whitespace can and cannot be dropped

The rules are asymmetric, and getting them wrong produces CSS that silently stops matching:

ContextSpaceReason
@media (min-width:1px)Required before (At-rule syntax
@media (a) and (b)Required after )Separates the query
a [href]Required before [Descendant combinator
[a] [b]Required after ]Descendant combinator
calc(1px + 2px)Required around +calc grammar
.a > .bDroppableChild combinator
h1 , h2DroppableSelector list

So an opening bracket licenses dropping only the space that follows it, and a closing bracket only the space that precedes it.

How much it saves

InputTypical reduction
Hand-written CSS with comments25-40%
Already-formatted framework output15-25%
Previously minifiedUnder 2%

Over HTTP with gzip or brotli, most of that saving disappears, since compression handles repeated whitespace very well. Minification still matters for the uncompressed size a browser has to parse, and for anything embedded inline in a page.

Beautifying

The beautifier normalises through the minifier first, then re-indents. That means it produces consistent output regardless of how the input was formatted, and round-tripping beautify then minify returns exactly the original minified form.

Common questions

Why do some minifiers break my CSS?

Because they use regular expressions. The moment a string contains something that looks like a comment or a brace, a regex-based minifier deletes the wrong thing, and content: "/*" is perfectly valid CSS. This one scans character by character and tracks whether it is inside a string, a comment or a url().

Why are spaces around a plus sign kept?

Because the calc() grammar requires them. calc(100% + 20px) is valid and calc(100%+20px) is not, and no minifier can tell the two contexts apart without a full parser. Keeping the space costs a couple of bytes on adjacent-sibling selectors and never produces broken CSS.

Are licence comments preserved?

Yes. Comments beginning /*! are kept, which is the long-standing convention for licence banners. Stripping a licence header is a legal problem, not a byte saving.

Is there a JavaScript minifier here?

No, deliberately. Minifying JavaScript safely requires a full parser. A regex approximation silently breaks regex literals, template strings and automatic semicolon insertion. Use esbuild, terser or swc, all of which parse properly.

Last reviewed