Skip to main content

How to Format CSS: Beautify Minified Stylesheets with a CSS Formatter

Turn minified, one-line CSS back into readable code. A practical guide to indentation, one declaration per line, reading bundled output, and local-only formatting.

Published By Li Lei
#css #formatting #web-development #frontend

How to Format CSS: Beautify Minified Stylesheets with a CSS Formatter

Open a compiled stylesheet and you will often find the same thing: one line, eighteen kilobytes wide, every space squeezed out, every rule jammed against the next. That shape is correct for the browser and useless for a human. When you need to read CSS — to find which rule paints a button blue, to confirm a vendor file sets no surprise overrides — you first have to put the whitespace back. That is all a CSS formatter does, and it is worth understanding exactly why it is safe to do.

Why CSS formatting is lossless

CSS has a small, blunt rule that makes this whole job trivial: whitespace between tokens is insignificant. A space, a newline, four spaces, a tab — to the parser they are the same separator. .btn{color:red} and the multi-line version below mean the exact same thing to the browser:

.btn {
  color: red;
}

Because of that, beautifying is a pure rewrite of layout, not of meaning. A good formatter never touches your values. #ffffff stays #ffffff and is not shortened to #fff. 0px stays 0px and is not collapsed to 0. 0.5rem stays 0.5rem, not .5rem. The only thing that changes is where the line breaks and how far each line is indented. That is what lets you format a file, run a diff against the original, and see no semantic difference — the bytes that matter are identical.

Three conventions do almost all the readability work:

  • Each selector gets its own block. .a,.b{...} becomes one rule with the selectors on their own lines, the braces on their own lines, and the declarations stacked inside.
  • One declaration per line. Every property: value; pair sits alone, so your eye scans a vertical list instead of hunting through a horizontal run of semicolons.
  • Consistent indentation. Two spaces, four spaces, or a tab — pick one and apply it everywhere, including inside nested @media and @keyframes blocks. Nesting depth becomes visible at a glance.

A worked example: minified rule to readable CSS

Here is a real-shaped fragment as you would find it inside a bundle — comments stripped, no spaces, several rules on one line:

.card{margin:0;padding:1rem;background:#ffffff;border:1px solid #e5e7eb}@media(max-width:640px){.card{padding:.5rem}}

Paste that into the CSS Formatter, choose two-space indent, and you get:

.card {
  margin: 0;
  padding: 1rem;
  background: #ffffff;
  border: 1px solid #e5e7eb;
}

@media (max-width: 640px) {
  .card {
    padding: .5rem;
  }
}

Notice what happened and what did not. The @media block kept its source order and got its own indentation level, so the responsive override is clearly inside the query. The #ffffff and .5rem came through untouched — the formatter did not "improve" them. The two rules that were glued together now sit apart, each with one declaration per line. You can read this. You could not read the first version.

Reading bundled and minified output

Most of the CSS you will ever need to format is not yours — it is build output. A framework's compiled theme, a third-party widget's stylesheet, a critical-CSS snippet someone inlined into <head>. These arrive minified by design, because shipping fewer bytes is the whole point of a build step.

The trap is that minified CSS is brace-fragile if you try to read it with regular expressions. Strings can contain braces (content: "}"), comments can contain anything, and nested at-rules stack braces several levels deep. A formatter that splits on { and } naively will mangle exactly the files you most need to inspect. The dependable approach is a brace-aware tokenizer that tracks string literals and comment spans, so a } inside content: "{ }" is never mistaken for the end of a rule. When you are auditing an unfamiliar stylesheet, that correctness is the difference between trusting the expanded output and second-guessing it.

Two more habits help when you are reading bundles:

  • Sort declarations only when it earns its keep. Alphabetizing properties within each rule (color, font, margin, z-index…) gives every rule the same shape, which shrinks noisy diffs. But leave it off when order is load-bearing — border then border-color must stay in that sequence, and alphabetical sort would flip them.
  • Don't expect SCSS to come out pretty. Native CSS nesting with & formats cleanly because it shares CSS's brace structure. But SCSS-only syntax — @include, $variables, %placeholders — is preserved verbatim, not reformatted. For full SCSS, reach for a SCSS-aware tool.

Format for reading, minify for shipping

Formatting and minifying are the same operation pointed in opposite directions. One adds whitespace for humans; the other removes every removable byte for the network. You will move between them constantly: expand a vendor file to understand it, then re-compress your own snippet before it ships.

I keep this loop tight in my own work. Last week a colleague pasted a 400-line compiled theme into a chat and asked why one button rendered the wrong shade. I dropped it into the formatter, hit Format with two-space indent, searched the expanded output for background, and found a single .btn { background: #2563eb } overriding our token three rules later. That took maybe thirty seconds. Reading it minified would have taken ten minutes of squinting, and I would not have trusted the result. When I needed to inline a hand-written critical-CSS block afterward, I ran the reverse pass through the CSS Minifier — comments and whitespace gone, values byte-identical, about 780 bytes down from 1.2KB, small enough to sit inside the HTML without hurting first paint.

Keep it local

There is one more reason to use an in-browser formatter rather than pasting CSS into a random web service: the CSS you most want to read is often the CSS you are least allowed to upload. Unreleased design tokens, internal theme files, a client's pre-release design system under NDA — all of it is exactly the kind of input you should not be sending to a third-party server.

A formatter that runs entirely in your browser tab solves that cleanly. The tokenizing, indenting, and sorting all happen client-side; nothing about the formatting step requires a network call. You can prove it: open DevTools, switch to the Network panel, and click Format or Minify. You should see zero requests fire. That makes it safe to expand and audit a stylesheet you would never be comfortable handing to an external API.

CSS formatting is one of those small jobs that quietly removes friction from a dozen daily tasks — reading bundles, reviewing diffs, shipping snippets, auditing unknowns. The mechanics are simple because the language cooperates: whitespace doesn't matter, so rearranging it is always safe. Give each selector its own block, put one declaration per line, indent consistently, and an unreadable wall of CSS becomes something you can actually reason about.

Made by Toolora · Updated 2026-06-13