HandyTools Hub
← Back to Tools

CSS Minifier/Formatter

Minify or beautify CSS code with custom indentation and comment options.

Minified or formatted CSS will appear here...

The CSS Formatter does two opposite jobs: it beautifies cramped, single-line stylesheets into readable indented rules, and it minifies verbose CSS down to the smallest valid form for production. Paste a stylesheet, choose a direction, and either way the output is ready to copy. Front-end developers use it to decode minified vendor CSS they need to override, to standardize formatting across a team, and to shave bytes off a stylesheet before deployment.

How to Use

  1. Paste your CSS into the input area. Both a neatly written file and a minified blob are fine — the tool reads either.
  2. Choose Format or Minify. Format adds line breaks and indentation; Minify removes all optional whitespace and comments.
  3. Check the output. The formatted result puts one declaration per line, which makes a missing semicolon or an unclosed brace visible immediately.
  4. Copy the result into your editor, build pipeline, or a bug report.

What Minification Actually Removes

Minification is narrower than people expect. It removes only characters the browser does not need:

  • Whitespace between tokens and newlines used purely for layout.
  • Comments such as /* ... */.
  • The last semicolon in a declaration block, and optional zeros in values.
  • Redundant units where the value is zero, such as 0px becoming 0.

It does not change selectors, property names, property values, or the cascade. color: #ff0000 and color: red behave identically, but a minifier will not convert one into the other, because that would alter the source in ways you did not ask for. The rule of thumb: minification changes the representation, never the meaning.

A Worked Example

A section of a base stylesheet:

/* Primary button */
.btn {
  display: inline-block;
  padding: 12px 20px;
  border: 1px solid #d1d5db;
  border-radius: 6px;
  background: #ffffff;
  color: #111827;
}

.btn:hover {
  background: #f3f4f6;
}

Formatted, the block above is already readable; run through Minify, it becomes a single line with the comment removed, roughly a third of the byte count. To inspect a real-world case, paste a minified third-party stylesheet and click Format: each rule expands onto its own lines, and the property you want to override — a specificity, a z-index, a hardcoded color — becomes findable in seconds instead of by scrolling a wall of text.

Formatting Conventions Worth Keeping

  • One selector per line, one declaration per line. This is the format that makes diffs meaningful in version control: a changed value touches one line, not the whole rule.
  • A consistent indent. Two spaces is the common default; two or four both work as long as the whole project agrees.
  • Property order. Some teams sort alphabetically; others group related properties (positioning, box model, typography, color). Alphabetical order is easier to enforce automatically, and it makes a rule scannable because you always know where margin will appear.
  • Shorthand carefully. margin: 0 10px is compact but hides which sides are set. Prefer explicit longhand when the intent matters, and run the formatter to keep it consistent.
  • Separate structure from theme. Keep layout rules and color/typography tokens in different files so a formatter run never tangles the two.

Common Mistakes

  • Editing the minified file. One line with thousands of rules is unmaintainable; always edit the source and re-minify.
  • Forgetting that comments disappear. Notes you rely on for section navigation vanish in the minified build. Keep a source-file copy.
  • Breaking calc() spacing. The operators + and − need surrounding spaces; a step that strips all whitespace inside calc() produces invalid CSS.
  • Minifying an already-minified file, repeatedly. Each pass is harmless for correctness but wastes time, and any accidental manual edit in between is easy to lose.
  • Assuming size numbers add up. The before-and-after figures measure raw bytes; the gzipped or Brotli-compressed transfer size will be smaller in both cases.

A final word on when formatting pays off. For a stylesheet you own, format it once at the start of a project and let a build step minify it on the way out — that keeps the readable copy in the repository and the compressed copy in the browser. Formatting is most valuable not as a routine but at the moments when whitespace is the obstacle: reading a vendored library, reviewing somebody else’s compressed output, or hunting a single broken declaration in a file that arrived as one long line.

Features

  • Beautify CSS with consistent indentation, one declaration per line
  • Minify to the smallest valid representation, stripping comments and optional whitespace
  • Handles media queries, nested at-rules, and modern CSS syntax
  • Before-and-after size display so you can see the effect
  • Works offline and never uploads your stylesheet
  • Instant, client-side processing — no sign-up

Use Cases

  • Decoding vendor CSS: Format a minified library file to find the rule you need to override.
  • Production builds: Minify a stylesheet before deploying to trim transfer size.
  • Code review: Normalize formatting so diffs show intent rather than whitespace.
  • Bug hunting: Expand a compressed rule to spot a typo or a missing semicolon.
  • Team consistency: Agree on one format and apply it across the project.

Frequently Asked Questions

Is minified CSS safe to deploy?

Yes, as long as you keep the original. Minification only removes whitespace, comments, and optional semicolons; it does not rewrite selectors or property values, so the browser sees an equivalent stylesheet. The practical rule is to treat the minified file as a build artifact: deploy it, but never edit it, because a compressed stylesheet with one line of thousands of rules is nearly impossible to maintain.

Are comments removed, and does that matter?

Comments are stripped in minified output, which is usually the point — license headers, section markers, and explanations are for developers, not browsers. Keep the comments in your source file. If a license requires the header to ship, preserve it separately with a tool that supports keeping the first comment.

Why does formatting change the spacing inside calc()?

CSS requires spaces around the + and − operators inside calc(); omitting them is invalid. A formatter that normalizes whitespace must therefore keep those spaces rather than collapsing them. If you write calc() by hand, remember that calc(100%-20px) is invalid, while calc(100% - 20px) works, and calc(100%/3) is fine because division does not need the spaces.

Will formatting fix invalid CSS?

No. Formatting reformats the text it is given; it cannot repair an unclosed brace, a missing semicolon before the next declaration, or a misspelled property. It can make those problems easier to spot, because each declaration sits on its own line, but validation and repair remain your job — check the output in the browser's inspector or a linter.

Does minification hurt gzip or Brotli compression?

It can remove some of the redundancy that compression exploits, so the compressed size may not shrink by the full amount shown in the tool's before-and-after numbers. Minification and compression still work together — you ship both — but the combined saving is usually smaller than either figure suggests when compared alone.

Is my CSS uploaded when I format it?

No. Formatting and minification run entirely in your browser with JavaScript. Stylesheets attached to an unreleased product, internal brand tokens, and anything else you would rather not share stay on your device.

Reviewed by the HandyTools Hub team · Last updated