CSS Formatter & Minifier

CSS in the wild is rarely as clean as the snippets in tutorials. A typical production stylesheet is the layered output of a preprocessor (Sass, Less, Stylus), a build pipeline (PostCSS with autoprefixer, cssnano, or similar), and sometimes a CMS or page builder that injects per-component overrides on top. The result, especially after minification for production, is often a single line of dense selector-and-declaration soup that is impossible to read, impossible to diff meaningfully, and impossible to reason about when something is misbehaving in DevTools. The formatter's job is to take that soup and turn it back into source-readable CSS: one selector per line in a comma-separated list, declarations indented and one per line, braces on the right, trailing semicolons preserved, comments respected. This is a normalization step, not a refactor — the resulting CSS is byte-equivalent in behavior to what you started with.

The formatter implementation here uses js-beautify's CSS mode, which handles the structural reformatting plus a handful of style choices around brace placement, selector wrapping, and declaration alignment. The configuration knobs we expose — indent size (2 or 4 spaces, or tabs), wrap width (40 / 80 / 120 / none), and a toggle for the trailing newline — cover what most teams care about. The defaults match what you would see in a typical production codebase: 2-space indent, 80-column wrap, trailing newline on. If your team has a different style guide, switch the indent and wrap settings; everything else is structural and not configurable, because deviations there tend to produce non-idiomatic CSS that confuses tooling later in the pipeline.

Minification works the same way the build-time minifiers do: strip comments (the /* ... */ blocks that document the source), collapse all whitespace runs to single spaces, remove space around the structural punctuation ({ } : ; , > ~ +), drop the last semicolon before each closing brace (it is optional in CSS and removing it saves a byte per rule), and concatenate everything onto one line. The byte savings tend to run 30-50% of the input for typical hand-written CSS and 10-20% for CSS that was already mostly minified — the difference depending on how much of the original was comments and how aggressively the original was already compressed. The minifier does not rename selectors or class names (that is a separate concern, handled by tools like cssnano with class-renaming plugins); it preserves identity so the resulting CSS works against the same HTML as before.

One subtle thing about CSS minification worth knowing: shorthand properties. The minifier here does not rewrite longhand to shorthand — `margin-top: 4px; margin-right: 8px; margin-bottom: 4px; margin-left: 8px` stays as four declarations, even though `margin: 4px 8px` would be shorter. The reason is that the rewrite is non-trivial and occasionally wrong (when later overrides expect specific longhands), so we leave it to dedicated tools that have the cascade analysis to do it safely. cssnano and clean-css both handle that rewrite as part of a build pipeline. For ad-hoc CSS minification — paste, click, copy — the byte-savings here are good enough without taking the risk of a semantic rewrite.

Where the formatter helps everyday work. Reviewing a component's stylesheet that arrived minified from a third-party library: paste, format, scan the output to understand the cascade. Diffing two versions of a stylesheet: format both first, then diff — the diff is meaningful only when the line breaks line up. Debugging a specificity issue in DevTools: copy the matched rules from the Computed pane, format them, see at a glance what is fighting what. Importing CSS into a CSS-in-JS codebase: format first, then convert (the conversion is mostly mechanical once the source is normalized). Teaching CSS authoring conventions to someone new — the formatter's output is a clean baseline.

Where the minifier helps. Production deployment of any hand-written CSS, especially for static sites and one-off landing pages where a build pipeline would be overkill. Email templates: HTML email rendering pulls inline styles directly from <style> tags, and minification reduces the email size for clients with envelope limits. CDN-served stylesheets: the savings compound when the CSS is delivered to many clients per hour. Embedded styles in HTML: when CSS is inlined inside a <style> block in HTML (rather than a separate file), minification helps both the embedded CSS and the surrounding HTML structure.

Edge cases worth knowing. CSS variables (--my-var) format and minify cleanly — they are just declarations from the parser's perspective. @media and @supports queries are handled as nested blocks with the right indentation. @keyframes blocks format with the percentage selectors on their own lines, which is the conventional style. @font-face blocks format like any other rule. Modern features (container queries, cascade layers, :has(), nesting) are supported by the formatter as long as the syntax is well-formed; the formatter does not validate or auto-correct, so syntax errors in the input will produce confused output. Run the input through a validator first if you suspect the source is malformed.

CSS nesting (the new W3C spec, supported in modern browsers from 2024) is preserved by the formatter — nested rules indent under their parent, mirroring the source structure. The minifier handles nesting by maintaining the structural braces; the byte savings are smaller for heavily nested CSS because the structural punctuation is the part that does not compress, but the savings on selectors and declarations are the same as for flat CSS. If your team is using nesting actively, the formatter output should look familiar, with the same indentation conventions that Sass authors used for the past decade.

Preprocessor output is a slightly different beast. The formatter handles the static-CSS parts of Sass, Less, or Stylus output without trouble, but the source-level constructs (mixins, variables, conditionals) are not present in the compiled CSS — they have been resolved by the preprocessor before output. The formatter operates on the compiled CSS, not the preprocessor source. If you have a .scss file you want to format, run it through Sass first to compile, then through the formatter; or use a Sass-aware formatter (Prettier's Sass plugin handles this directly). The same applies to PostCSS output, where any plugin transformations have already been applied before the formatter sees the input.

Privacy is the same as the rest of our tools: nothing is uploaded, nothing is logged, the formatter and minifier run entirely in your browser. The CSS you paste, including any inline references to internal URLs, internal class names, or any pre-release styles, never leaves your device. You can verify by opening the network tab during formatting — there are no outbound requests beyond the static page assets. This is meaningful when the CSS contains evidence about your design system, internal product names, or partner integrations that you would not want to expose to a third-party server.

Workflow tip: when comparing two stylesheets, format both at the same settings before diffing. A diff between two formatted stylesheets surfaces real semantic changes; a diff between an unformatted and a formatted version is mostly noise from the whitespace differences. The same applies in reverse for minification: when reviewing whether a minified output preserves the original semantics, format both the source and the minified-then-reformatted version and diff them — they should be nearly identical, with the only differences being shorthand collapsing or comment stripping (depending on the minifier's options).

The tool pairs naturally with adjacent utilities. The HTML Formatter handles the markup that the CSS styles. The JS Formatter is the third leg of the front-end formatting trio. The Markdown ↔ HTML Converter is useful when documentation includes both Markdown content and inline CSS examples. The Regex Tester helps with the bulk-edit workflow where you want to update a class name across a stylesheet. The JSON Viewer is useful for design-token files that often live alongside CSS in modern frontends, and the Hash Generator is helpful when generating cache-busting hashes for deployed CSS files. Together, these cover most of the front-end author's daily formatting and inspection needs.