Orpheus

Minify CSS

Comments, whitespace and the last semicolon.

Options
Remove comments
Shorten colours and zero units
Result

Everything is processed in this tab. Nothing you paste is sent anywhere.

Every tool runs entirely in your browser. Your files are never uploaded to a server.

Minifying CSS removes comments and whitespace the parser ignores, and can shorten #ffffff to #fff and 0px to 0. Strings are left alone, because whitespace inside them is rendered content.

How to use CSS Minifier

  1. Paste your CSS. A single rule or a whole stylesheet.
  2. Choose the optimisations. Comment removal and value shortening are independent.
  3. Copy the result. Bytes saved are shown as an absolute and a percentage.

About minifying CSS

CSS minification removes what the parser ignores: comments, the whitespace between tokens, and the final semicolon before a closing brace. None of it changes how the stylesheet is interpreted, which is what makes minification safe in principle. In practice the safety depends on knowing where the parser stops ignoring things. Strings are the boundary. A content property with deliberate spacing renders that spacing, a url() may contain characters that mean something to the tokeniser, and a quoted font family can contain whatever the font is called. Collapsing whitespace inside any of those changes behaviour, so strings are extracted before the whitespace pass and restored afterwards. A minifier that runs a global whitespace collapse over the whole file will eventually corrupt one of them. Value shortening is a second category and is more nuanced than it appears. A six-digit hex colour can be shortened to three only when each pair repeats, and a zero length needs no unit — but a zero time does in some contexts, where a bare 0 is invalid. Excluding time units is the kind of distinction that separates a minifier you can run on a real stylesheet from one that works on the example in its own documentation. It is also worth keeping expectations calibrated. Twenty to thirty percent of raw bytes is a typical saving, and most of that is whitespace that compression was already handling. Over a gzipped connection the real gain is a few percent — genuinely worth having in a build step, and not a reason to make source unreadable.

Frequently asked questions

Why are strings left untouched?
Because their contents are rendered. A content property containing deliberate spaces displays those spaces, and collapsing them changes the page. The same applies to url() values and to font names, so strings are lifted out before anything else happens.
What is a /*! comment?
The conventional marker for a comment that must survive minification, used for licence and attribution headers. Every mainstream minifier respects it, and stripping it from a library can breach the terms it was distributed under.
Is shortening 0px to 0 always safe?
For lengths, yes — a zero length is unitless by specification. For times it is not: some contexts require 0s rather than a bare 0, so time units are deliberately excluded here. It is a small saving with a real failure mode if applied indiscriminately.
Does removing the last semicolon break anything?
No. The semicolon before a closing brace is a separator with nothing after it to separate, so it is optional by specification. Keeping it in source is good practice because it makes adding the next declaration safer; removing it in output is free.
How much does this save in practice?
Typically 20 to 30% of raw bytes and considerably less after compression, since gzip and Brotli already encode repeated whitespace efficiently. The gain over a compressed connection is usually a few percent, which is worth taking in a build step and not worth hand-editing for.

Last updated