CSS Minifier
Shrink CSS by removing comments and whitespace only — no value rewriting, no rule merging, nothing that can change how your page renders.
Your CSS
Minified CSS
Most of the bytes in a hand-written stylesheet are not CSS. They are the indentation, the blank lines between sections, and the comments explaining why a hack exists. Removing them typically takes 15 to 30 per cent off a pretty-printed file before compression, and it is the only part of minification that is guaranteed not to change what the browser renders.
That guarantee is the design constraint here. This is a conservative custom minifier, not an optimising one. It strips comments and collapses whitespace, and it stops there. It does not rewrite values, merge rules, drop declarations it thinks are redundant, or reorder anything. If you are used to cssnano or Lightning CSS, expect a smaller saving from this tool — and expect never to spend an afternoon bisecting a visual regression caused by an over-clever optimisation.
How to use the css minifier
- 1
Paste the stylesheet you want to compress
Paste, drag a
.cssfile onto the pane, or use Upload File. Output written by the CSS formatter is an ideal input, since it is already parsed and consistent. - 2
Minify
The result appears as a single line, with a summary of the original size, the minified size and the exact percentage saved so you can judge whether the change is worth making.
- 3
Copy or download
Copy the compact text to your clipboard, or download it as a
.cssfile. To expand it again later, paste it into the CSS formatter — the round trip is lossless apart from the comments you asked to remove.
Exactly what is removed
The minifier walks the stylesheet character by character rather than firing regular expressions at it, so it always knows whether it is inside a string. That distinction is where naive minifiers break. Specifically:
- Comments are removed, with one exception: a comment opening with
/*!is a licence banner by long-standing convention and is preserved verbatim. That is what keeps you compliant with MIT and Apache attribution requirements when you ship a bundled third-party stylesheet. - Runs of whitespace collapse to a single space, and the space is then removed entirely around the structural characters
{}:;,>~and+. - The final semicolon before a closing brace is dropped, since it is syntactically optional.
- String contents are never touched. A declaration such as
content: "/* not a comment */"keeps its exact text, including the spaces and the comment-like characters, because the minifier tracks the open quote and copies everything through until the matching close. Escaped quotes inside strings are handled too.
What an optimising minifier would do, and why this one does not
Tools such as cssnano, Lightning CSS and esbuild go considerably further. They shorten #ffffff to #fff and named colours to hex, drop leading zeros from 0.5em, collapse margin: 10px 10px 10px 10px into margin: 10px, merge adjacent rules that share a selector, merge longhand properties into shorthands, remove declarations they consider duplicates, and sometimes reorder rules that they can prove do not conflict.
Every one of those transformations is safe in the general case and unsafe in specific ones. Merging longhands into a shorthand resets the properties you did not mention. Removing a "duplicate" declaration destroys an intentional fallback for an older browser — the classic pattern where a plain rgb() value precedes a color-mix() value is exactly two declarations of the same property, and one of them looks redundant. Collapsing rules changes source order and therefore specificity tie-breaks.
Those tools are trustworthy inside your build, where you have a test suite, visual regression snapshots and a git history to bisect. In a browser text box, on CSS you pasted from a system you may not own, you have none of that. So this tool restricts itself to the transformations that cannot alter rendering, and tells you plainly that is what it is doing.
How much this actually matters over the wire
Minification and compression solve overlapping problems, and compression usually wins. CSS is extremely repetitive text, so gzip and Brotli compress it dramatically — a 100 KB stylesheet often lands under 15 KB with Brotli. Removing whitespace before compression still helps, but far less than the raw percentage suggests, because whitespace is precisely the sort of repetition the compressor was already handling well.
Minifying is genuinely worth it when: you are inlining critical CSS into a <style> block in the document head, where every byte is in the critical path and blocks rendering; you are embedding CSS into a JSON payload, an email template or a database column; you are shipping a widget or embed that must stay under a size budget; or your host does not compress text/css responses at all, which is still surprisingly common on cheap static hosting.
It is not worth it for a file under version control that a human reads, and it is redundant if your bundler already minifies during the build.
CSS Minifier FAQ
Can minifying break my styles?
Only whitespace and comments are removed, and string contents are protected, so ordinary stylesheets are safe. The one thing to know is that whitespace is meaningful in a few places CSS beginners do not expect — inside calc(), around the descendant combinator, and inside attribute selectors — and a single space is preserved in all of them rather than being removed.
Why is my saving smaller than another minifier reported?
Because this one does not rewrite your values or merge your rules. An optimising minifier reports a bigger number by making changes this tool deliberately refuses to make. Compare the two outputs: the extra saving is almost always colour shortening and shorthand merging.
Are licence comments preserved?
Yes. Any comment beginning /*! is kept exactly as written, including its line breaks. Ordinary /* … */ comments are removed. If you need a comment to survive, add the exclamation mark.
Can I reverse the minification?
You can re-expand the structure by pasting the output into the CSS formatter, which will restore indentation and line breaks. The comments you removed are gone for good — keep the original in version control.
Does it work on SCSS or Less?
No. Pre-processor sources contain nesting, variables and mixin calls that are not valid CSS, and collapsing their whitespace can corrupt them. Compile to CSS first, then minify the compiled output.