CSS Formatter

Stylesheets tend to decay. A file that started tidy accumulates rules pasted from Stack Overflow, output from a build tool, and edits made in a hurry — and because CSS ignores whitespace, nothing forces it back into shape. That cost shows up when you need to change something: a declaration you cannot find, a media query whose closing brace is ambiguous, or a diff that reports a hundred changed lines because one formatting pass ran differently. Reindenting is the cheapest way to make a stylesheet reviewable again, and because it provably cannot change behaviour, it is a safe first step before any real refactor.

These two tools are exact opposites and both belong in a normal workflow. You format while you are working: reading a vendor stylesheet, reviewing a change, or hunting down which rule sets a colour. You minify at the end, when the file is about to be served to a browser that does not care about readability and does care about bytes. The important rule is that neither should be a one-way door — keep your formatted CSS in version control as the source of truth, and treat minified output as a build artefact you can always regenerate.

It rebuilds the whitespace in your stylesheet without changing what the CSS does. Every rule gets its own lines, declarations are indented consistently, and braces land in predictable places. Minified CSS arrives as one enormous line where a single selector can be impossible to find; formatting turns that back into something you can read, review in a pull request, and debug. The selectors, properties, and values themselves are untouched, so the rendered result is identical before and after.

No. Whitespace between CSS tokens is not significant, so adding newlines and indentation cannot alter which rules match or which declarations win. The one thing worth knowing is that formatting does not resolve specificity conflicts or reorder anything — if two rules were fighting before, they are still fighting after, just in a layout where you can finally see them.

Two is the most common convention in CSS and is what most style guides and formatters default to, largely because nested at-rules and long selector lists eat horizontal space quickly. Four reads more clearly for shallow files. The honest answer is that it matters far less than being consistent across a codebase — pick whichever your project already uses and set it in All options.

It handles the CSS-compatible parts of SCSS and LESS well, including nesting and at-rules, because the brace-and-declaration structure is the same. Preprocessor-only syntax such as mixins, functions, and @each loops will pass through but is not specifically understood. Compiled Tailwind output formats cleanly, though bear in mind a full Tailwind build is tens of thousands of lines, so you usually want to format only the section you are inspecting.

No. Every one of these tools runs entirely in your browser using JavaScript. Your stylesheet is never uploaded, never logged, and never sent to any server — you can confirm this by opening your browser devtools Network tab while you work, or by disconnecting from the internet after the page loads and watching everything continue to function. That makes it safe to paste proprietary or client CSS.