CSS Beautifier & Minifier — Free Online Tool

What is CSS Beautifier & Minifier?

Pretty-printing CSS means giving every declaration its own line and indenting each block by its brace depth, so a stylesheet's structure — which rules sit inside which at-rule — is readable without counting braces. This tool tokenises the input into comments, quoted strings and code before it touches any whitespace, which is why a semicolon inside content: "a;b" or a brace inside a URL cannot be mistaken for structure.

• Beautify keeps comments, Minify drops them: Beautify moves each /* … */ comment onto its own line and restores it verbatim, so licence headers and section markers survive. Minify removes every comment — including /*! banners — and reports the resulting character count.
• Brace-depth indentation: Indent is computed from nesting, so declarations inside a @media, @supports, @layer or @container block are indented one level deeper than the at-rule, and native CSS nesting (& .title { … }) indents correctly too.
• Property spacing is normalised: A single space is enforced after the colon in each declaration, so color:red and color :red both become color: red. Selectors containing :: or a :hover pseudo-class are left alone, as are at-rule preludes and anything containing ://.
• Minify is conservative: It collapses all whitespace, removes spaces around { } : ; , > ~ + ( ) and !, and drops the final semicolon before a closing brace. It does not rename anything, shorten colours, merge rules, or reorder declarations — so the output is byte-smaller but semantically identical.
• Seven indent presets: 1, 2, 3, 4 and 8 spaces plus 1 tab and 2 tabs. Two spaces is what the Google HTML/CSS style guide specifies; tab options emit real tab characters.

Why use the CSS beautifier?

A minified stylesheet is a single line with no structural cues, and CSS gives you no error messages to work from — an invalid declaration is silently dropped. Formatting is how you get the structure back so you can see what is actually there.

• Reveals what a build produced: Beautify the CSS a bundler, a preprocessor, or a CSS-in-JS runtime emitted and you can see the real selectors, the real specificity, and the media queries your source did not obviously ask for.
• Finds duplicate and overridden declarations: Once each declaration is on its own line, two rules setting the same property on the same selector are visible, and so is the later one that is winning. That is the fastest way to explain "why is my colour being ignored".
• Makes at-rule nesting legible: Deeply nested @supports inside @media inside @layer is unreadable minified. Indentation by brace depth tells you immediately which conditions a rule is actually gated behind.
• Reviewable diffs: A one-line stylesheet diffs as one changed line. Beautify both revisions with the same indent width and a reviewer can point at the declaration that changed.
• Byte measurement without a build: Minify prints the exact output length, so you can see what a set of comments or a formatting convention costs before compression, and compare two authoring approaches quickly.
• Runs locally: Nothing is uploaded. Stylesheets from a client project, an authenticated admin theme, or an unreleased design system stay in the browser.

When to use the CSS beautifier

Reach for it when a stylesheet is unreadable, when a rule is not applying, or when you need to know what the bytes cost.

• Reading a minified .css file pulled from a CDN, a Sources panel, or a competitor's site to understand how something was built.
• Debugging a specificity or cascade problem, where you need to see every rule that touches a selector, in source order.
• Auditing an unfamiliar theme or vendor stylesheet before overriding it, so you know which media queries and layers exist.
• Normalising formatting on a stylesheet edited by several people, before committing, so future diffs are about declarations rather than whitespace.
• Minifying a small standalone stylesheet — an email template, a print sheet, an embeddable widget — without setting up a build pipeline.
• Checking whether a comment block, a licence banner, or generated source-map comment is still present in a shipped file.
• Preparing a readable snippet for documentation, a style guide, or a bug report.

How to use the CSS beautifier

One input pane, one output pane, two actions. The indent setting only affects Beautify.

1. Paste or upload your CSS: Paste into the "CSS in" pane, or press Upload .css to load a file. The picker only accepts .css, and the contents are checked for braces, semicolons or an @ before loading.
2. Choose an indent width: 1, 2, 3, 4 or 8 spaces, or 1 or 2 tabs. Two spaces matches the Google style guide and most web toolchains; pick whatever the repository already uses so you do not create whitespace-only diffs.
3. Press Beautify: Each declaration goes on its own line, blocks are indented by brace depth, a single space is enforced after each property colon, and comments are placed on their own lines with their text unchanged.
4. Or press Minify: All comments are stripped, whitespace collapses, spaces around structural punctuation are removed, and ;} becomes }. The status line reports the output length, for example "Minified (1284 chars)".
5. Scan the result for problems: Look for repeated properties in one block, rules that are more deeply nested than you expected, and any block whose closing brace is at the wrong indent level — that last one means the braces do not balance.
6. Copy or download: Use the controls on the output pane. If you edited the input, re-run the action; the output does not update on its own.

Key features

• String- and comment-aware tokeniser: The input is split into comment, string and code tokens first, so a ; or { inside content: "…", a url(), or an attribute selector value is never treated as structure.
• Comments preserved on beautify: Each comment is swapped for a placeholder during formatting and restored byte-for-byte on its own line, so licence headers and section dividers stay intact.
• Nesting and at-rule support: Indent follows brace depth, so @media, @supports, @layer, @container and native CSS nesting with & all format at the correct level.
• Colon normalisation that skips selectors: Only lines that look like declarations get their colon spacing fixed; lines starting with @ or /*, and anything containing ://, are left as authored.
• Conservative minification: Whitespace and comments only. No colour shortening, no property merging, no selector rewriting — so nothing can change how the stylesheet cascades.
• Character-count feedback: Minify reports the exact output length, giving you a quick before-and-after measure without a build step.

Common use cases

• Reading shipped CSS: Beautify a minified production stylesheet to see the selectors and media queries a build actually emitted.
• Cascade debugging: Format a stylesheet so competing declarations on the same selector line up and the winning one is obvious.
• Theme auditing: Inspect a vendor or CMS theme before overriding it, so you know its layers, breakpoints and specificity.
• Pre-commit normalisation: Apply one indent convention to a file several people have edited, so future diffs are meaningful.
• Standalone minification: Shrink an email, print, or widget stylesheet where adding a bundler would be overkill.
• Documentation snippets: Produce clean, consistently indented CSS examples for a style guide or a bug report.

Examples

Actual output from this tool. Indent is 2 spaces unless noted.

/* layout */
@media (min-width:640px){.card{display:flex;gap:1rem}.card>h2{font-size:1.25rem;margin:0}}

/* layout */
@media (min-width:640px) { .card { display: flex; gap: 1rem } .card>h2 { font-size: 1.25rem; margin: 0 }
}

/* theme */
:root { --brand: #2563eb;
}
a:hover , a:focus-visible { color : var(--brand);
}

:root{--brand:#2563eb}a:hover,a:focus-visible{color:var(--brand)}

.card{color:red;& .title{font-weight:700}}

.card { color: red; & .title { font-weight: 700 }
}

.note::before{content:"a; b";color:#333}

.note::before { content: "a; b"; color: #333
}

Technical reference

The CSS syntax rules this tool relies on:

Specification

CSS Syntax Module Level 3 (tokenising and parsing); CSS Cascade and Inheritance Level 5 for @layer

Comment syntax

/* … */ only. CSS has no line-comment form — a // comment is a Sass/Less feature and is invalid in plain CSS

Whitespace tokens

Space (U+0020), tab (U+0009), line feed (U+000A), carriage return and form feed. Whitespace is insignificant except inside strings and as a descendant combinator

Final semicolon

Optional before a closing brace. Minify removes it; keeping it in source is the safer convention because appending a declaration then cannot break the previous one

Error handling

CSS recovers silently: an unknown property or invalid value causes the declaration to be dropped, and a malformed selector invalidates the whole rule. No error is surfaced anywhere

Nesting

CSS Nesting Level 1 allows a style rule inside a style rule, with & referring to the parent. Supported in all current major browsers

Indent convention

The Google HTML/CSS Style Guide specifies 2 spaces per level, one declaration per line, and a space after each colon

Custom properties

--name: value is parsed as an almost-arbitrary token stream, so its value is preserved as authored rather than normalised

Common mistakes to avoid

Using // for comments in plain CSS

Why it happens: CSS Syntax Level 3 defines only /* … */. A // line is not a comment; the parser treats it as the start of a declaration or selector it cannot understand, discards tokens until it recovers, and usually eats the declaration or rule that follows. Nothing is reported, so the symptom is a style that mysteriously stops applying one line below the comment. The habit comes from Sass, Less and Stylus, where // is stripped at compile time and never reaches the browser.

How to avoid it: Use /* … */ in any file that is served as CSS. If you author in Sass or Less, // is fine in source but check the compiled output — this tool's Beautify makes surviving // lines easy to spot because they are placed as code, not as comments. When you inherit a file with // comments, convert them before minifying, since a minifier will happily collapse the following rule into the broken line.

Expecting minification to also optimise the CSS

Why it happens: This tool's Minify is a whitespace-and-comment pass by design: it does not shorten #ffffff to #fff, merge duplicate selectors, drop unused rules, or collapse margin shorthands. People often compare its output against a full optimiser such as cssnano or Lightning CSS and conclude the minifier is broken, when in fact it is deliberately non-semantic — the point is that nothing about the cascade can change.

How to avoid it: Use this for a fast, safe size reduction on a standalone file, and use a real optimiser in a build pipeline when you want value-level rewrites, deduplication, or dead-rule removal. If your goal is smaller shipped CSS, the biggest wins are usually removing unused rules and enabling Brotli, not squeezing bytes out of the ones you keep.

Omitting the final semicolon in source because it is optional

Why it happens: CSS lets you drop the semicolon on the last declaration in a block, and minifiers remove it. But in source, that missing semicolon is a trap: the next person appends a declaration on a new line, and the two now parse as one malformed declaration. CSS error recovery drops it silently, so a property that looks perfectly correct simply has no effect and there is nothing in the console to explain why.

How to avoid it: Always terminate every declaration with a semicolon in source, including the last one, and let the minifier strip it at build time. If a declaration you just added has no effect, check the line above it for a missing semicolon before you suspect specificity. Beautify puts every declaration on its own line, which makes a run-together pair easy to see.

Stripping /*! licence banners with a generic minifier

Why it happens: Many open-source stylesheets carry an attribution or licence header in a comment, and licences such as MIT require the notice to be retained in distributed copies. Convention marks those as /*! … */ so tools can preserve them. This tool's Minify removes every comment, including /*! ones, so a naive copy-paste round trip can quietly drop a notice you are obliged to keep.

How to avoid it: Check the input for /*! blocks before minifying, and re-add them to the top of the output by hand, or configure a build-time minifier with a comments option that preserves them. If you are bundling third-party CSS, collect licence text into a single banner or a separate NOTICE file so it does not depend on a minifier's default behaviour.

Frequently asked questions

How do I beautify minified CSS from a production site?

Copy the stylesheet text — from the Sources panel, a view-source tab, or the .css file itself — paste it into the input, pick an indent width, and press Beautify. Each declaration lands on its own line and every block is indented by brace depth, including @media, @supports, @layer, @container and native nesting. Comments are kept. For very large files, upload the .css instead of pasting to avoid clipboard limits. The result is for reading and reviewing; keep the original if the file is one you are going to ship.

Does CSS support // comments?

No. CSS Syntax Level 3 defines exactly one comment form, /* … */, and there is no line-comment token. A // in a stylesheet is parsed as garbage: the parser discards tokens until it can resynchronise, which usually consumes the declaration or rule immediately after it. Because CSS error handling is silent, you get no console message — just a style that stops working. The // form belongs to Sass, Less and Stylus, where it is removed during compilation and never appears in the served file.

How much smaller does minifying CSS actually make a file?

Whitespace-and-comment minification typically removes 10–30% of the raw characters, depending on how heavily commented and indented the source is. After Brotli or gzip the saving is much smaller — often only a few percent — because compression already handles repeated indentation well. The bigger wins for shipped CSS are removing rules nothing uses and making sure text compression is enabled on the server. Press Minify here to see the exact character count for your own file rather than working from averages.

Is the last semicolon in a CSS block required?

No, it is optional before the closing brace, and minifiers remove it to save a byte. In authored source you should still write it. Without it, appending a new declaration underneath produces one run-together declaration that CSS silently discards, and there is no error message to point you at the cause. The safe convention is: semicolon after every declaration in source, let the build strip the last one. This tool's Minify removes it; Beautify does not add it back, so a block ending without one is normal output.

Will formatting CSS change how my page renders?

No. Outside of strings, CSS whitespace is insignificant, so adding or removing indentation and newlines cannot alter the cascade, specificity, or computed values. The one thing to watch is that Minify deletes comments, so if a comment was carrying a licence notice, a source-map reference, or a directive a downstream tool reads, that information is lost. Beautify keeps comments verbatim. Neither action renames selectors, reorders declarations, or rewrites values, so both are safe round trips for rendering purposes.

Can it format Sass, Less, or CSS with nesting?

Native CSS nesting works fully: because indentation is computed from brace depth, a rule written as .card { & .title { … } } formats at the correct level with no configuration. Sass and Less files will mostly format too, since their block structure is the same, but preprocessor-only syntax is not understood — // comments are treated as code rather than comments, and @mixin or @include preludes are passed through as text rather than reflowed. For serious preprocessor work use your toolchain's own formatter; use this for the compiled CSS.

References

• W3C — CSS Syntax Module Level 3
• MDN — Using CSS nesting
• MDN — Specificity
• Google HTML/CSS Style Guide
• web.dev — Minify CSS