CSS Formatter & Minifier

Beautify or minify CSS — comments and string values are preserved either way.

CSS Input

body {
  margin: 0;
  font-family: sans-serif;
}
.card {
  padding: 16px;
  border-radius: 8px;
  background: #fff;
}
@media(max-width:600px) {
  .card {
    padding: 8px;
  }
}

Beautifying & minifying CSS

Minified or hand-mangled CSS is hard to read and edit. Beautifyre-indents each rule, puts every declaration on its own line, and adds a space after each colon — while a state-aware parser keeps your comments and string values (like content: "a b") exactly as written, never collapsing their whitespace. Minify runs the real csso optimizer to shrink the stylesheet for production. Everything happens locally in your browser.

Built and maintained by Meet Shah · Last updated 24 July 2026

What this tool is used for

Making a minified stylesheet readable enough to find which rule sets a property.
Normalising a file that several people have edited with different conventions.
Reading a fragment pasted from a devtools panel with no line breaks.
Checking the real nesting of a media query or a nested selector.
Preparing a stylesheet for review so the diff shows rule changes rather than formatting.

Frequently Asked Questions

Does formatting change what my CSS does?: No. Whitespace between declarations is insignificant in CSS, so re-indenting cannot alter the cascade. The one place whitespace matters is inside values — the descendant combinator in `.a .b` and the space-separated parts of a `grid-template` — and those are left untouched.
How is a nested block indented?: By counting braces: every `{` opens a level and every `}` closes one, so `@media` and `@supports` blocks indent their contents one step further. That is also why a file with an unbalanced brace formats strangely — the indentation is the first place a missing `}` shows up.
Should I commit minified or formatted CSS?: Formatted. Minify in the build, not in the repository — a minified file makes every diff one enormous line, which destroys code review and blame. The bytes you save in git are worth nothing; the bytes you save at the CDN are the ones that matter.
Tabs or spaces for CSS?: Two spaces is the near-universal convention in CSS, unlike the genuine tabs-versus-spaces split in general programming. Whatever you choose, put it in `.editorconfig` and a formatter so it is never decided in review.
Does it fix errors?: No — this is a formatter, not a validator or an autoprefixer. A misspelled property is re-indented and left in place, because a browser ignores declarations it does not understand and a formatter that dropped them would be silently changing your stylesheet.
Does formatting change specificity or the cascade?: No — whitespace between selectors and declarations is insignificant in CSS, so the parsed rules are identical. The only thing formatting changes is what a diff looks like, which is why it belongs in a separate commit.

Common errors and gotchas

Expecting formatting to change specificity or order. It does neither, and both determine what actually applies.
Assuming it validates. An unknown property formats perfectly and still does nothing in a browser.
Reformatting a file with a custom property whose value is a token list, where spacing can be meaningful.
Losing a hack that depended on exact syntax, such as a starred property or a deliberate parse error.
Formatting output that a build step will minify anyway, then committing the expanded version by mistake.