Formatting is not cosmetic when you are reading code you did not write. A single line stylesheet hides the nesting of media queries, makes it impossible to tell where one selector list ends and the next begins, and turns a two character typo into a twenty minute search. Restoring the line breaks restores the structure the author originally had.
Nothing is uploaded. The stylesheet is parsed and reprinted by JavaScript running inside your own tab, which means a proprietary theme or a client project stays on your machine. This CSS formatter has no queue, no size cap and no account, so you can format css online as often as you like.
When you should reach for a CSS beautifier
The common case is debugging production output. Deployed stylesheets are minified, and browser devtools show you the computed values rather than the source that produced them. Pulling the served file through a css beautifier gives you something you can actually read alongside the devtools panel.
The second case is a diff that has become useless. If a build tool has rewritten a stylesheet onto fewer lines, every change looks like the whole file changed. Formatting both sides with identical settings makes the real difference visible again.
- You are reading a minified stylesheet served from a CDN and need to find one rule.
- A colleague pasted a block of CSS into chat and every line break was lost.
- You want to indent css code consistently before committing it to a repository.
- A diff is unreadable because the two versions use different line breaking.
- You inherited a stylesheet with mixed tabs, spaces and brace styles.
How this CSS formatter handles strings, comments and url values
Whitespace inside a CSS string is meaningful. A content property can legitimately hold two spaces, and a url() value can contain a data URI thousands of characters long that must not be broken. Naive formatters that run a regular expression over the whole file corrupt exactly these cases.
The scanner here tracks its own state. While it is inside single quotes, double quotes, a comment or the parentheses of a url() function, it copies characters through untouched and does not treat a brace or a semicolon as structural. Only outside all of those does it insert line breaks and indentation.
Comments are preserved by default because they frequently carry licence headers that must survive. You can drop them with a toggle when you want the shortest readable output, but the default is to keep everything the author wrote.
Choosing an indent width and brace style
Two spaces is the dominant convention in modern CSS and the default here. Four spaces suits stylesheets with shallow nesting where you want each level to be unmistakable. Tabs are the right answer when your team lets each developer set their own visual width, since a tab is one character that renders however the reader configured it.
Brace placement is fixed to the same line as the selector, which is what every major style guide and every popular formatter produces. Putting the opening brace on its own line is legal CSS but it doubles the vertical cost of a short rule, and in a file with hundreds of rules that matters.
Whatever you pick, the important property is consistency across the file. Mixed indentation is worse than any single choice, because it makes the nesting depth ambiguous at a glance.
What the CSS formatter deliberately does not change
The CSS formatter reprints your stylesheet. It does not rewrite it. Declaration order inside a rule is preserved exactly, because CSS cascade rules mean the last declaration wins and reordering can silently change rendering. Selector lists keep their original order for the same reason.
Shorthand is left alone. A margin declaration written as four values stays as four values, and a colour written as a hex triplet is not expanded to a functional notation. Vendor prefixes are untouched, and so is anything the parser does not recognise, including at rules from newer specifications that this scanner has never heard of.
That conservatism is the point. A formatter that also optimises is a formatter you have to review, and reviewing is exactly the work you were trying to avoid.
Formatting compiled output from Sass, Less and PostCSS
Preprocessor output is the most common input to this tool after minified production files. Compiled Sass often arrives with the nesting flattened into long selector chains, and generated media queries can end up scattered through the file rather than grouped. Formatting will not regroup them, but it will make the grouping visible so you can decide whether the source needs restructuring.
PostCSS plugins that inline custom properties or add fallbacks produce duplicated declarations that look like a mistake until you see them on separate lines. Once the file is formatted you can read the fallback pair as the intentional pattern it is.
If you plan to pretty print css that came out of a bundler, format the file before you start annotating it rather than after. Reindenting a file you have already added comments to moves your comments around and makes the annotation harder to follow.
| Property | Formatted | Minified |
|---|---|---|
| Line breaks | One declaration per line | None |
| Comments | Preserved by default | Usually stripped |
| Typical size change | Grows 20 to 40 percent | Shrinks 15 to 30 percent |
| Best used for | Reading, reviewing, diffing | Serving to browsers |
| Rendering result | Identical | Identical |
How to use the CSS formatter
- 1
Add your stylesheet
Paste CSS into the input box or drop a .css file onto the drop area. The file is read locally and never transmitted.
- 2
Pick an indent
Choose two spaces, four spaces or a tab. Two spaces matches the convention used by most modern stylesheets.
- 3
Decide about comments
Leave comments on to preserve licence headers and author notes, or turn them off for the most compact readable output.
- 4
Format and copy
Press format, then copy the result to the clipboard or download it as a .css file ready to commit.
Related tools worth bookmarking
Sources and further reading
Frequently asked questions
Common questions about the css formatter.
No. Only whitespace between tokens is altered, and whitespace outside strings is not significant in CSS. Declaration order, selector order, shorthand values and vendor prefixes are all preserved exactly as you wrote them, so the computed styles are identical.
Usually yes. The scanner is tolerant rather than strict, so an unclosed brace or a stray character is copied through instead of aborting the run. The output will show the damage clearly, which often makes the error easier to locate than the original single line file.
Yes. Everything between the parentheses of a url() function is copied through byte for byte, including base64 data URIs that run to thousands of characters and contain semicolons and commas that would otherwise look structural to a formatter.
No. All of the work happens in your browser using plain JavaScript. Open the network panel of your developer tools and format a file while watching it, and you will see no request carrying your stylesheet anywhere.
Formatting adds whitespace so a human can read the file. Minifying removes whitespace so a browser downloads fewer bytes. They are exact opposites, and a normal workflow uses a formatter during development and a minifier as the last step before deployment.