Free · Fast · Privacy-first

Decompress Minified CSS Online

Minified CSS is intentionally unreadable: whitespace is stripped, comments are removed, and every rule is collapsed onto as few characters as possible.

⚡

Restores whitespace, newlines, and indentation removed by minifiers

🔒

Works on any valid minified CSS including complex at-rules

✨

All processing happens in your browser, code never sent to a server

⚡

No sign-up or installation required

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 Minification Removes and Why Reversing It Matters

CSS minification is a one-way compression step applied during a build process. Tools like cssnano, clean-css, and UglifyCSS parse a stylesheet and discard everything a browser does not need to apply styles: indentation spaces, newlines between rules, spaces around colons and semicolons, blank lines separating rule blocks, and all comment text. The resulting file is semantically identical to the original, but stripped of every character that exists only for human readability. A 200-line stylesheet can collapse to a single line of several hundred characters. That is efficient for transfer, but completely opaque to anyone trying to read it.

Decompressing reverses the whitespace removal step. A decompressor parses the minified token stream, which contains every selector, property, value, and at-rule keyword, and rebuilds a formatted representation with consistent indentation and line breaks. The output matches what the original developer would have written if they had followed a standard formatting convention. What cannot be recovered is anything that was truly discarded: comments and any original variable names that were renamed by an aggressive build tool. Those tokens no longer exist in the minified file and cannot be reconstructed.

The most common reason developers need to decompress minified CSS is debugging a live site. When a visual bug appears in production and you cannot locate it in your source files, the production CSS is the ground truth. DevTools shows you the applied rules, but the Sources panel often shows the minified file. Decompressing that file gives you a readable copy you can search, compare, and reason about. It is also useful when inheriting a project that has only compiled assets and no source files.

Source map availability changes the decompression calculus. If a .css.map file is referenced via a sourceMappingURL comment at the end of the minified file and the map is publicly reachable, Chrome and Firefox DevTools will transparently substitute the original authored source in the Sources panel, complete with comments and original variable names. Decompression then becomes a fallback rather than the primary path. Many production deployments deliberately omit or 404 the map for security or bandwidth reasons, in which case the decompressed file is the only readable artifact available. Before pasting into FixTools, scroll to the bottom of the minified content and check for a sourceMappingURL line: if it points to an accessible map, fetch and use that for the highest fidelity reading; if it is missing or returns an error, decompression remains the right tool. Treat the two as complementary rather than competing approaches.

MDN Web Docs: CSS Syntax W3C CSS Syntax Level 3 Specification

How to use this tool

💡

Paste your minified CSS into the input panel and click Unminify. The output shows fully expanded, indented CSS with each rule on its own line and each property properly indented beneath its selector.

How It Works

Step-by-step guide to decompress minified css online:

1
Copy the minified CSS
Open the minified CSS file or copy the production stylesheet content from your browser DevTools Network tab response body. The content will appear as a dense, single-line or near-single-line block of CSS text.
2
Paste into FixTools
Open the CSS Unminifier and paste the copied minified content into the input panel on the left side of the tool.
3
Click Unminify or Beautify
Click the Unminify button. The tool parses the compressed token stream and outputs fully formatted CSS with each selector, declaration block, and property on separate lines with consistent indentation.
4
Copy and use the readable output
Click Copy to Clipboard to grab the decompressed CSS. Open it in your code editor for reading, searching, or comparison against your source files.

Real-world examples

Common situations where this approach makes a real difference:

Debugging a production visual regression

A developer notices a layout breaks only on the live site. The source files in the repository look correct. They open Chrome DevTools, copy the minified stylesheet from the Network tab, decompress it with FixTools, then search the output for the suspect class name. The decompressed file reveals that a merged shorthand property in the production build has a value different from the source, pointing to a build configuration issue rather than a code bug.

Inheriting a project with no source files

A freelancer takes over a client website where the previous developer left only compiled assets. The CSS is minified and no source SCSS or original stylesheet exists. The freelancer decompresses the minified CSS to get a readable starting point, then structures it into logical sections before making any changes. This gives them a working development copy without needing to reverse-engineer every style from scratch.

Comparing a third-party component update

A team upgrades a third-party UI library and notices visual changes in their app. Both the old and new minified CSS bundles are decompressed using FixTools, then compared in a diff checker. The diff reveals that the library changed several default padding values in a specific component, which explains the layout shift they observed.

Recovering styles from a cached CDN file

A developer needs to understand the styles applied by a CDN-hosted stylesheet they do not control. They open the CDN URL in a browser, copy the response from the Network tab, and decompress it to read the rules. This allows them to write targeted overrides in their own stylesheet without guessing at the specificity or property values they need to beat.

Pro tips

Get better results with these expert suggestions:

Copy from the Network tab, not the Sources tab

In Chrome DevTools, the Sources tab sometimes shows a source-mapped version of your CSS rather than the raw minified file. For the true production CSS that browsers are actually receiving, go to the Network tab, find the CSS request, and copy the response body. That is the minified string you want to paste into the decompressor.

Check for multiple stylesheets in one file

Build tools that bundle multiple CSS files into one minified output will concatenate them. After decompressing, you may find several logical stylesheets joined end to end. Look for comment markers that some build tools insert as boundaries, or for abrupt style jumps, to identify where one original file ended and another began.

Validate after decompressing if you plan to edit

If you intend to edit the decompressed CSS and redeploy it, run the output through a CSS validator first. Decompression faithfully reproduces the minified content, including any invalid rules that were present. Knowing about errors before editing prevents confusing cascade behaviour later.

cssnano and clean-css produce slightly different minified outputs

cssnano (used by webpack and PostCSS pipelines) and clean-css (used by Grunt and Gulp plugins) make different optimisation decisions. cssnano may merge adjacent rules while clean-css may not. Recognising the output style can tell you which build tool produced the minified file, which helps when tracing back to the source project.

Use the decompressed output as a reference, not a source file

Decompressed CSS is useful for reading and debugging, but it may not match the style conventions of your project. Use it to understand the production rules, then apply fixes in your actual source files and rebuild.

Look for selector grouping after decompression

Some minifiers merge selectors with identical declarations. After decompressing, check whether rules that appear grouped were originally separate in your source. This can affect specificity calculations if you edit the decompressed output directly.

Pair with a diff tool to compare versions

After decompressing both an old and a new version of a minified stylesheet, run them through a diff checker to see exactly what rules changed between builds.

FAQ

Frequently asked questions

Decompressing minified CSS reverses the whitespace removal that minifiers apply. A minifier collapses all rule blocks onto as few lines as possible, removes indentation, strips comments, and eliminates spaces around colons and braces. Decompression parses those same tokens and reinserts standardised whitespace, placing each selector, declaration block, and property on its own line. The resulting CSS is byte-for-byte functionally identical to the minified version; only the formatting changes. Nothing that was removed by the minifier, such as code comments or renamed variables, can be restored because those tokens no longer exist in the file.

Yes. cssnano produces standard minified CSS that any decompressor can expand. cssnano applies several optimisations beyond simple whitespace removal: it merges adjacent rules, converts hex colours to shorter keywords, removes redundant properties within shorthand declarations, and reorders certain values. All of these optimisations preserve semantic equivalence, so the decompressed output will show the merged or converted values rather than the originals. The resulting code is correct and readable, even though it may not exactly match the pre-cssnano source file.

Minifiers often apply semantic optimisations in addition to whitespace removal. cssnano may merge adjacent selectors with identical declarations, convert longhand properties to shorthand, normalise colour values, and remove properties overridden elsewhere in the same block. clean-css makes similar optimisations. The decompressed CSS reflects whatever survived those optimisations and made it into the minified file. If you need the original source, you need the source file itself. The decompressor can only recover what the minifier retained, not what it discarded or transformed.

It is workable but not ideal. Decompressed CSS is a readable version of what the minifier produced, which may include merged rules, converted shorthand properties, and normalised values that differ from what a developer would typically write. If you plan to maintain the file long-term, spend time reorganising the decompressed output: split merged rules, restore logical groupings, and add comments where needed. Treat decompression as a starting point for reconstruction rather than a finished source file.

Open Chrome or Firefox DevTools with F12. Click the Network tab and reload the page. Filter requests by type CSS. Click the stylesheet request you want, then click the Response sub-tab to see the raw response body. Select all the content and copy it. In Chrome, you can also right-click the stylesheet URL in the Sources panel and choose Open in new tab to get the raw minified file. Paste whatever you copy directly into the FixTools CSS Unminifier input panel.

No. All processing runs in your browser using client-side JavaScript. When you paste CSS and click Unminify, the code is parsed and reformatted entirely within your browser tab. Nothing is transmitted to any server. This is important when working with proprietary stylesheets, client code, or any CSS that you would not want a third party to see. The privacy guarantee is a direct result of the browser-based architecture, not a policy promise.

Any syntactically valid CSS can be decompressed, including media queries, @keyframes animations, @supports blocks, @font-face declarations, CSS custom properties, pseudo-classes and pseudo-elements, attribute selectors, and modern features like container queries and cascade layers. The decompressor handles nested at-rules by applying an additional level of indentation to their contents. If the input CSS contains a syntax error, the decompressor will attempt to handle it gracefully, though output near the error may be unexpected.

Yes. Vendor-prefixed properties such as -webkit-transform, -moz-appearance, and -ms-flex are treated as standard property tokens by the decompressor. They are placed on their own lines with the same indentation as any other property. Some build tools like Autoprefixer add these during a PostCSS build step, so the minified CSS may contain more prefixed properties than your original source had. The decompressor expands all of them faithfully. Inspecting these expanded prefixes is often the fastest way to diagnose a browser-specific bug: if a layout works in Chrome but fails in Safari, scanning the unminified output for missing -webkit- variants of properties like backdrop-filter, mask-image, or clip-path will usually surface the cause within a few seconds. Older minified bundles may also contain -o- and -ms- prefixes for legacy Opera and Internet Explorer support that you can safely strip out of your source, and the decompressed view makes those redundant declarations easy to identify at a glance so you can update your Browserslist configuration to stop emitting them on future builds.

FixTools decompresses with two-space indentation per nesting level, which matches the default convention used by Prettier, Stylelint, and most modern CSS style guides including the Google and Airbnb conventions. Two spaces keeps deeply nested @supports inside @media inside @layer blocks readable without horizontal scrolling, which becomes a real problem at four-space depth once you reach three or four levels. If your project standard is four spaces or tabs, copy the decompressed output into your editor and run your formatter (Prettier, Stylelint with the indentation rule, or VS Code Format Document) to re-indent. The decompression step gives you a clean structural baseline that any downstream formatter can then re-style without ambiguity.

Yes, decompression invalidates any existing source map. Source maps record line and column offsets in the minified file and translate them back to original source positions. Adding whitespace shifts every offset, so the map no longer aligns with the decompressed output. The original .css.map file is still valid for the original minified file, but it will produce incorrect mappings if used against the decompressed copy. If you need source map support after decompression, your options are to keep working from the original minified file with the map attached in DevTools, or to regenerate a fresh map by re-minifying the decompressed CSS through a build tool that emits a new sourceMappingURL. Mixing the two artifacts produces misleading debugging output.