CSS Beautifier and Minifier_
Both directions on one page, because that is how CSS is actually used: format a stylesheet to read it, then compact it again to ship it. The counts above tell you what is in the file — how many rules, how many declarations, and how many !important flags somebody left behind.
Minifying here removes whitespace and comments and nothing else. Your colours are not shortened, your zeros keep their units and your rules are not merged, because each of those rewrites is usually safe and occasionally changes what a stylesheet means.
- Input
- Any CSS — a minified bundle, a framework's build output, or a file written by someone with different habits. Modern syntax including nesting, layers and container queries passes through untouched.
- Output
- Indented CSS at your chosen width, or a single compact line. Both preserve exactly what the stylesheet selects and applies.
- Processing
- Formatted and compacted in this tab. A stylesheet is often unreleased design work, and there is nowhere for it to go from here.
- Limits
- The minifier is whitespace and comments only. Aggressive tools also rewrite values and merge rules; that is a different trade and this one does not make it.
- A space is a selector
- In CSS whitespace is sometimes syntax. `.a .b` matches a .b inside a .a; `.a.b` matches an element with both classes. Inside calc(), min(), max() and clamp() the spaces around + and − are required by the grammar — calc(100% -20px) is not a subtraction, it is an error. A minifier that treats space as noise silently breaks both, and the tests here pin exactly those cases.
Where CSS whitespace stops being optional
The descendant combinator is a space
Most punctuation in CSS can lose the space around it — a > b and a>b are identical, as are color: red and color:red. But between two simple selectors the space is the operator. Removing it from .card .title produces .card.title, which stops matching a title inside a card and starts matching an element carrying both classes. Nothing errors, the stylesheet still parses, and a rule quietly stops applying.
And calc() insists on its spaces
calc(100% - 20px) needs the spaces around the minus sign, because without them the parser reads -20px as a negative length rather than a subtraction and the expression is invalid. The plus sign has the same rule; multiplication and division do not, which is exactly the sort of inconsistency that makes a naive minifier look correct on half its test cases. min(), max() and clamp() share the grammar and the requirement.
What aggressive minifiers do that this one will not
A serious build-time minifier shortens #ffffff to #fff, drops the unit from 0px, folds four margin declarations into one shorthand, and merges rules with identical bodies. Each is usually right. Shorthand, though, resets properties you did not mention — writing margin where you had only set margin-top also sets the other three to zero — and merging changes the order rules appear in, which is what the cascade uses to break ties. Those are decisions for a tool that runs in your build with your test suite behind it, not for a text box.
Reading a stylesheet you did not write
Formatting is the first step; the counts are the second. A file with hundreds of !important flags is telling you its specificity is out of control, and one with selectors four levels deep is telling you the same thing more politely. Both numbers appear above, and both are worth reading before you add a rule of your own — because the reason your new declaration is not applying is usually already visible in them.
Formatting will not fix a broken stylesheet
CSS is forward-compatible by design: a browser skips a declaration it does not understand and carries on, which is why an unclosed brace or a missing semicolon can silently disable everything after it rather than raising an error. A formatter shows you the shape of what you wrote, and if the indentation suddenly runs away halfway down the file, that point is usually where the brace went missing. It is a symptom worth reading, not a repair.
Format to read it, minify to ship it
- 01Paste the CSS or upload a file. Beautify is selected, so a minified stylesheet becomes readable straight away.
- 02Read the counts: rules, declarations, !important flags and selectors four levels deep or more. Those four numbers describe the file faster than scrolling does.
- 03Press Minify to go the other way. The size figure shows what came off, and the output keeps every space the language actually needs.
- 04Change the indent if your project uses tabs or four spaces. It affects the beautified output only.
A production stylesheet you need to read
One long line from a build. Formatting restores the structure, and unlike JavaScript nothing was renamed — CSS minifiers do not touch class names, so what you get back is genuinely readable.
.card .title{font-size:1.25rem;margin:0 0 .5rem}.card p{color:#666}.card .title {
font-size: 1.25rem;
margin: 0 0 .5rem
}
.card p {
color: #666
}The space that changes a selector
This is the mistake a careless minifier makes, and nothing reports it. The rule keeps parsing and stops matching.
.card .title { color: red }.card.title{color:red}
/* now matches an element with BOTH
classes, not a title inside a card */calc() that stops working when compacted
The spaces around the minus sign are part of the grammar. Removing them turns a subtraction into an invalid value, and the declaration is dropped.
width: calc(100% - 20px)
width: calc(100% -20px) /* parsed as two lengths, not a subtraction — the rule is dropped */
Auditing a stylesheet before you add to it
Your new rule is not applying and you want to know why. The counts usually answer it before you open devtools.
rules: 812 declarations: 2,140 !important: 137 deep selectors: 296
Specificity is being fought, not designed. Your rule is losing to one of those 137.
What minifying removes, and what it must not
| In the source | Minified | Why |
|---|---|---|
a > b, color: red | Space removed | Punctuation carries the meaning; the space around it is decoration. |
.a .b | Space kept | The space is the descendant combinator. Removing it changes which elements match. |
calc(100% - 20px) | Spaces kept | Required by the grammar around + and −. Without them the value is invalid and dropped. |
1px solid red | Spaces kept | They separate the values of a shorthand and cannot be recovered from context. |
content: " x " | Kept exactly | Whitespace inside a string is content, and rendering depends on it. |
/* a note */ | Removed | Comments are for the author, not the browser. |
/*! licence */ | Kept | The bang is the convention for text that must survive minification. |
#ffffff, 0px | Unchanged | Rewriting values is a different operation with different risks. This tool declines it. |
Every row here is a test. The two marked as kept for grammatical reasons — the descendant combinator and the calc spaces — are the two things a minifier written with a regular expression gets wrong, so they are pinned first.
Working with other people's CSS
- Read the !important count before adding a rule. A high number means specificity is being fought rather than designed, and your new declaration is probably losing to one of them.
- Use a build-time minifier for production. This one is deliberately conservative; a real build tool with your tests behind it can safely do the value rewriting this declines.
- Watch where the indentation runs away. CSS does not error on a missing brace, so the point where the structure goes strange is usually the point where the file broke.
- Keep framework CSS as the framework ships it. Formatting a vendor stylesheet and committing the result guarantees a painful conflict at the next upgrade, when the whole file is replaced wholesale.
- Check the size figure against what your server sends. Compression removes most of what minification does, so if gzip is already on, the saving on the wire is far smaller than the saving on disk.
Where CSS tools go wrong
A minifier that eats the descendant combinator
Turning .a .b into .a.b produces valid CSS that selects something else. No error is raised anywhere, and the symptom is a rule that simply stops applying.
calc() compacted into a syntax error
The spaces around + and − are grammar, not formatting. Remove them and the browser discards the whole declaration, which usually shows up as a layout collapsing at one breakpoint.
Shorthand folding that resets what you did not set
Merging margin-top into margin also sets right, bottom and left to their initial values. Aggressive minifiers handle this correctly; hand-written ones frequently do not.
Formatting treated as validation
CSS skips what it cannot parse rather than failing, so a stylesheet full of mistakes formats perfectly. A clean-looking result is not evidence the file works.
Engines, syntax and what is counted
- Beautifier
- js-beautify's CSS formatter, the same one behind most editor commands of that name. It adjusts whitespace around the declarations you wrote and does not reprint the file from a parse tree.
- Minifier
- A single-pass scanner written for this page. It removes whitespace and comments only, and preserves the descendant combinator, the spaces calc-family functions require, string contents and unquoted url() paths.
- Forward compatibility
- A scanner rather than a parser, deliberately: CSS is designed so that unknown at-rules and functions are skipped rather than rejected, and a stylesheet using syntax newer than this page must still survive it.
- Counts
- Rules, declarations, !important flags, selectors of four or more parts, and media queries — measured after stripping comments and string contents so neither contaminates the total.
- Not done
- No value rewriting, no shorthand folding, no rule merging, no vendor-prefix handling, and no autoprefixing. Those belong in a build.
- File handling
- Uploads are read inside the page with the browser File API and are never transmitted; Download writes out what is already in the tab.
- Network
- None from tool code. A test sweep calls every function this page uses with
fetchandXMLHttpRequestreplaced by stubs that throw, so a stray request fails the build instead of shipping. Disconnect from the network and the page still works.
Questions about formatting and minifying CSS
Does minifying CSS ever break a stylesheet?
It can, and the two ways are specific. Removing the space in a descendant selector changes what the rule matches; removing the spaces around + or − inside calc() makes the value invalid so the declaration is dropped. Both produce CSS that still parses, which is why neither raises an error. This minifier preserves both, and the tests pin them.
Why is my minified CSS still large?
Because whitespace was never most of it. Selectors, property names and values are the bulk of a stylesheet, and none of them can be removed. If the file is large after minifying, the answer is usually unused rules rather than formatting — and compression on the server removes most of what is left.
Should I minify CSS if my server uses gzip?
Expect much less than the file-size figure suggests. Stylesheets compress unusually well — the same property names recur on almost every rule, which is exactly the redundancy a compressor is built to exploit — so most of what minification removes has already been paid for by the time the bytes reach the wire. Minify because your build does it anyway, or because the file is stored somewhere raw.
Why does this not shorten #ffffff to #fff?
Because value rewriting is a different operation with a different risk profile. Colour shortening is safe, but the same class of transformation includes shorthand folding and rule merging, which can reset properties you never set and reorder the cascade. A build tool with your tests behind it can make those trades; a text box should not.
What is the difference between a CSS formatter and a beautifier?
The words are interchangeable here and everywhere else. What is worth distinguishing in CSS is formatting from OPTIMISING: this page changes layout only, while a build-time optimiser also rewrites values, folds shorthand and drops rules it believes are unused. The second kind needs your test suite behind it.
Can I recover the original CSS from a minified file?
Almost entirely, which is different from JavaScript. CSS minifiers do not rename anything, because class names are part of the public interface between the stylesheet and the markup. Formatting a minified stylesheet gives you back a genuinely readable file, minus the comments.
Why did my rule stop applying after I minified?
Check the selector for a lost space first — .a .b becoming .a.b is the classic. Then check any calc() values for missing spaces around the operators. Both are silent, and both are what a regular-expression minifier gets wrong.
Does my stylesheet leave the browser?
No. The work is JavaScript running in this tab. Every function it calls is covered by a test that stubs fetch and XMLHttpRequest to throw, so a request that slipped in would break the build rather than reach a server — and you can confirm it for yourself by disconnecting and carrying on.