Free · Fast · Privacy-first

Reverse CSS Minification

CSS minification applies a series of transformations to reduce file size.

⚡

Reverses whitespace removal from cssnano, clean-css, and UglifyCSS output

🔒

Restores indentation, newlines, and spacing between all tokens

✨

Preserves all semantic content unchanged (selectors, values, at-rules)

⚡

Browser-based: paste minified CSS and get readable output instantly

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this Unminifier Beautifier to your website

Drop the Unminifier Beautifier into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/css-tool/unminifier-beautifier?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Unminifier Beautifier by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/css-tool/unminifier-beautifier?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Unminifier Beautifier by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

What cssnano, clean-css, and UglifyCSS Remove During Minification

cssnano is the most widely used CSS minifier. It runs as a PostCSS plugin and is the default minifier in webpack's css-minimizer-webpack-plugin. cssnano applies several transformation passes. The first removes all whitespace: spaces, tabs, and newlines that are not part of a string value. The second removes all comments. The third applies semantic optimisations: it uses cssnano's preset-default configuration to merge adjacent rules with identical declarations, remove duplicate properties within a rule, convert hex colours to shorter forms, strip zero units, normalise url() paths, and more. clean-css, which powers Grunt and Gulp CSS minification plugins, applies similar transformations with some differences in which semantic optimisations it enables by default. UglifyCSS is a simpler tool that focuses primarily on whitespace removal with fewer semantic optimisations.

Understanding which tool produced a minified file can help you interpret the output. cssnano-minified CSS often shows merged selector groups (multiple comma-separated selectors where the original source had separate rules) and normalised colour values. clean-css output may have slightly different shorthand property consolidations. UglifyCSS output will more closely resemble the original source structure since it applies fewer semantic changes. If you are debugging a build pipeline issue, knowing which minifier is in use helps you predict which transformations to look for.

Reversing minification restores whitespace exactly. The reversal process parses the minified token stream using the CSS grammar and reinserts standardised whitespace at every structural boundary. A newline and indentation appear before each declaration. A newline appears after each closing brace. A space appears between the selector and the opening brace. All at-rule contents are indented one additional level. What the reversal does not restore is any information that was discarded rather than compressed: code comments are gone, original variable name choices are gone (if a build tool renamed them), and any values that were optimised into a different but equivalent form reflect the optimised form.

Source maps deserve explicit consideration before you reach for the reversal tool. Most modern minifier configurations emit a .css.map file and reference it via a sourceMappingURL comment at the bottom of the minified CSS. When the map is reachable, Chrome and Firefox DevTools transparently substitute the original authored source in the Sources panel, complete with comments, original variable names, and preprocessor structure. That is strictly higher fidelity than any reversal output because it shows what the developer actually wrote rather than what survived minification. Production deployments often strip or 404 the map for security and bandwidth reasons. Before pasting into FixTools, check the last few lines of the minified content for a sourceMappingURL directive and fetch the referenced map directly. If it loads, prefer DevTools with the map attached. If it returns an error, the reversal is your best available path to readable code.

cssnano Documentation clean-css GitHub Repository

How to use this tool

💡

Paste the minified output from cssnano, clean-css, UglifyCSS, or any other CSS minifier. The reversal process re-expands all compressed rule blocks and declaration lists, producing formatted code with proper indentation throughout.

How It Works

Step-by-step guide to reverse css minification:

1
Identify the minified CSS source and its origin
Note which build tool generated the minified CSS (webpack with cssnano, Vite with Lightning CSS, Gulp with clean-css) if known. This context helps you interpret the reversed output. Copy the minified CSS from the build output file or the production server response.
2
Paste into FixTools and reverse
Open FixTools CSS Unminifier, paste the minified content, and click Unminify. The tool reverses the whitespace removal across all rule types, at-rules, and declaration lists.
3
Identify minifier-specific transformations in the output
Scan the reversed output for merged selector groups (cssnano), consolidated shorthand properties (clean-css), or inline @import statements. These patterns are evidence of specific minifier optimisations that you should account for if you plan to edit the reversed code.
4
Compare against source if available
If the original source file exists, open both the reversed output and the source side by side in a diff tool. Differences between them represent the semantic optimisations the minifier applied. Use this comparison to understand exactly what the build pipeline changed.

Real-world examples

Common situations where this approach makes a real difference:

Diagnosing an unexpected minifier behaviour

A developer adds a new CSS rule and the production site renders differently than expected. They reverse the minified production CSS and compare it against the source. The comparison reveals that cssnano's mergeRules plugin combined their new rule with an adjacent rule that had identical declarations, changing the selector list. The developer adds a comment between the two rules to prevent merging, rebuilds, and the production CSS matches expectations.

Verifying a migration from clean-css to cssnano

A team migrates their build pipeline from Gulp with clean-css to webpack with cssnano. They reverse both the old clean-css output and the new cssnano output, then compare the two formatted files. The comparison shows that cssnano applies more colour shortening and merges several rule sets that clean-css left separate. They adjust their cssnano configuration to disable mergeRules and rebuild, producing output that more closely matches their expected structure.

Understanding what Lightning CSS preserved vs optimised

A developer using Vite (which uses Lightning CSS for minification) wants to understand what Lightning CSS changed in their stylesheet. They reverse the minified output and compare it against the source SCSS compiled output. The comparison shows that Lightning CSS inlined several custom property var() calls and removed some vendor prefixes that it determined were no longer needed for the configured browser targets. This confirms the build is correctly targeting modern browsers.

Investigating a production CSS anomaly report

A QA engineer reports that a colour on the live site does not match the design spec. A developer reverses the production minified CSS and searches for the component's class name. The reversed output shows that the background-color value is a three-digit hex that, when expanded to six digits, does not match the design token. They trace the issue back to a naming collision where two similar class names had different intended colours but cssnano merged their rules because their other declarations matched.

Pro tips

Get better results with these expert suggestions:

Identify cssnano-merged rules by looking for comma selector groups

cssnano's mergeRules plugin combines selectors that share identical declaration blocks. After reversing, a rule like h1, h2, h3 { font-weight: bold } where the original source had three separate rules is a sign of cssnano with mergeRules enabled. If you need to edit only one of those selectors, split the merged rule back into separate blocks first.

Recognise clean-css shorthand consolidation

clean-css consolidates longhand properties into shorthands. Four separate margin properties become margin: top right bottom left. If the reversed output shows shorthand properties for margin, padding, border, or background that you originally wrote as longhands, clean-css combined them. You can safely re-expand them to longhands if your project uses that style.

Test reversal output byte count against the minified input

A healthy reversal should produce a file around three to six times the character count of the minified input, depending on how heavily commented and spaced the original source was. If the reversed output is less than double the minified input, the input may have been a small snippet rather than a complete stylesheet.

Use reversal to verify build pipeline optimisations

After changing minifier configuration (switching from cssnano default to advanced, or enabling additional clean-css optimisation levels), reverse the new minified output and compare it against the previously reversed output. This shows you exactly what additional transformations the new configuration applied, helping you confirm the change had the intended effect.

Check your build tool to identify which minifier was used

webpack uses css-minimizer-webpack-plugin (cssnano by default). Vite uses Lightning CSS or esbuild. Gulp and Grunt projects typically use clean-css via gulp-clean-css. Knowing the minifier tells you which semantic optimisations were applied and sets expectations for what the reversed output will look like.

Use a source map if one is available

Before reversing minification manually, check whether the build produced a source map (.css.map file). Source maps allow Chrome DevTools to show you the original source file directly in the Sources panel. If a source map is available, use it in DevTools rather than reversing the minified output.

Compare cssnano levels for different build outputs

cssnano has multiple optimisation presets. The default preset applies moderate optimisations. The advanced preset applies aggressive rule merging. If the reversed output looks more transformed than expected, the build may have used the advanced preset.

FAQ

Frequently asked questions

cssnano's default preset applies many optimisations on top of whitespace removal. It removes duplicate properties within a rule, keeping only the last declaration. It merges adjacent rules that share identical declarations, combining their selectors. It converts hex colours to shorter equivalents where possible. It removes units from zero values. It normalises url() values by removing quotes when safe. It discards the last semicolon in a rule block. It removes all CSS comments. Each of these is a separate PostCSS plugin within the preset, and individual plugins can be enabled or disabled through cssnano configuration.

Both tools produce minified CSS, but their default behaviour differs. clean-css uses a level system: level 1 does whitespace removal and comment stripping, level 2 adds semantic optimisations like property merging and rule restructuring. The default level is 1, making clean-css more conservative than cssnano's default preset. cssnano's preset-default includes many of the level-2-equivalent optimisations by default. For this reason, cssnano output is often more transformed relative to the source, while clean-css level 1 output more closely reflects the original structure.

Yes, particularly when you reverse both a previous minified version and a current minified version and compare them. The comparison shows precisely which rules, properties, or values changed between builds. This is more informative than comparing minified files directly because character-level diffs of minified CSS are nearly unreadable. Reversing both versions and diffing the formatted output gives you a meaningful, rule-level view of what the build changed.

UglifyCSS is an older CSS minifier that focuses primarily on whitespace removal with minimal semantic optimisations. It does not merge rules, consolidate shorthands, or apply value transformations to the degree that cssnano and clean-css do. It was popular in early Node.js-based build toolchains but has largely been replaced by cssnano in modern webpack and PostCSS pipelines. If you are working with CSS from a legacy build system using UglifyCSS, the reversed output will look more similar to the original source since fewer semantic transformations were applied.

Yes. Lightning CSS (used by Vite and Parcel) produces standard minified CSS that the reversal process handles fully. Lightning CSS is notable for natively handling vendor prefixes (removing them for unsupported browsers based on a target configuration), CSS nesting, and custom media queries as part of its transformation pipeline. The reversed output reflects the CSS as Lightning CSS produced it after these transformations, not the original authored CSS before them.

No. cssnano removes all CSS comments by default. Once removed, comment text is not stored anywhere in the minified output and cannot be recovered. Some cssnano configurations use the discardComments plugin with a keepSpecialComments option to preserve comments that start with /*! (licence comments). If the original CSS used this convention and the build was configured to preserve such comments, they will appear in the minified file and therefore in the reversed output. Normal developer comments without the ! marker are always discarded.

Source maps are generated during the build process and map each position in the minified file back to the corresponding position in the original source. When DevTools uses a source map, it shows you the original authored CSS (or SCSS) as you wrote it, including comments and your formatting style. Reversing minification without a source map reconstructs a formatted version of the minified output, which reflects the minifier's optimised form of the code. Source maps are more accurate when available; reversing minification is the approach when source maps are absent.

Double-minified CSS (minified, then minified again) is unusual but possible in misconfigured build pipelines. The second minification pass typically has nothing to remove since the first pass already stripped all whitespace. The resulting file is identical or nearly identical to the first-pass output. Reversing a double-minified file works the same way as reversing any minified CSS: the reversal process operates on the token stream, which is identical regardless of how many minification passes produced it.

Vendor prefixes are restored exactly as they appear in the minified file. Autoprefixer typically emits prefixed variants in a specific order: -webkit-, -moz-, -ms-, then the unprefixed standard property. cssnano and clean-css preserve that order during minification, and the reversal places each variant on its own indented line in the same sequence. The order matters because browsers apply the last matching declaration, so the standard property must come last for modern browsers to use it. After reversal, the prefixed lines become a useful audit surface: search for -webkit- and cross-check each property against current Browserslist targets to identify obsolete prefixes that no longer correspond to any browser receiving security updates. Trimming those from the source typically shrinks the next production build by several percent.

The reversal output uses two-space indentation, which is the dominant modern convention and the Prettier default. Two spaces keeps deeply nested @supports inside @media inside @layer blocks readable without horizontal scrolling, which matters once you reach three or four nesting levels. If your project uses four-space indentation or tabs, treat the reversal output as an intermediate artifact and re-indent it with Stylelint's indentation rule, Prettier with a custom tabWidth, or your editor's Convert Indentation command. The mechanical re-indent step takes seconds and produces a file that matches your existing code style. The common pitfall is committing the reversed two-space output directly into a four-space repository, because the next developer to edit triggers a formatter and creates a noisy diff that mixes their real change with the indentation flip.