Free · Fast · Privacy-first

Convert Minified CSS to Readable Code

Minified CSS looks nothing like the stylesheet a developer originally wrote.

⚡

Expands compressed selector blocks and declaration lists to individual lines

🔒

Reveals the full property names and values hidden in compact notation

✨

Works with colour shorthand, combined selectors, and shortened values

⚡

No setup: works instantly in any modern browser

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 Minified CSS Looks Like Versus Its Expanded Form

A typical minified CSS rule like .nav{display:flex;align-items:center;padding:0 16px;background:#fff;color:#222} started as a multi-line block with each property on its own indented line, blank lines between rule blocks, and possibly an explanatory comment above the selector. Minifiers systematically remove every character that is not syntactically required: the space between .nav and the opening brace, the newline and indentation before display, the spaces around the colon in display:flex, all newlines between declarations, and the space before the closing brace. The result occupies one line of densely packed characters that is impossible to scan.

Beyond simple whitespace removal, minifiers apply value optimisations that change the representation of certain values without changing their computed result. cssnano converts #ffffff to #fff and #222222 to #222. It converts padding: 0px 16px to padding:0 16px by removing the unit from zero values. It may convert margin: 0px 0px 0px 0px to margin:0. clean-css applies similar transformations, and some configurations of both tools will convert longhand properties like border-top-style: solid, border-top-width: 1px, and border-top-color: #000 into the shorthand border-top: 1px solid #000. All of these transformations are semantically equivalent but look different from the original source.

When you convert minified CSS to readable form, the output shows the transformed values, not the originals. A hex colour that the source file had as a custom property reference or a variable will appear as the resolved hex value if the minifier inlined it. A margin that the developer wrote as margin-top: 8px may appear as part of a shorthand margin: 8px 0 if the minifier combined it with other margin declarations. Understanding these transformations helps you interpret the readable output correctly and avoid confusion when the expanded code does not exactly match what you remember writing.

Line length and wrapping become live questions once the CSS is readable. A typical declaration fits comfortably within 80 characters, but several common patterns blow past that: comma-separated selector groups that cssnano merged from several source rules, font-family stacks listing six or seven fallbacks, gradient values with four or more colour stops, and box-shadow declarations with multi-layer composites. The readable output keeps each declaration on a single line regardless of length, which is the right default because hard-wrapping inside a value adds whitespace that the browser does not expect and can interact awkwardly with certain calc() and var() compositions. If a single line truly exceeds your team's comfort threshold (most projects settle between 100 and 120 characters), the structural fixes are to split a merged selector group, extract a long value into a custom property, or move a complex gradient to its own variable. Arbitrary mid-value line breaks usually create more friction than they relieve.

MDN Web Docs: Shorthand Properties cssnano: PostCSS-based CSS Minifier

How to use this tool

💡

Paste minified CSS containing shortened values, concatenated selectors, and collapsed rule blocks. The readable output restores each rule to separate lines with properly indented declarations, making every property and value easy to read.

How It Works

Step-by-step guide to convert minified css to readable code:

1
Locate the minified CSS source
Identify the minified CSS you want to read. This could be a .min.css file from a build output folder, a response from the browser Network tab, or a CSS string in a JavaScript bundle.
2
Copy the full minified content
Select and copy the entire minified CSS content. Partial copies produce incomplete readable output. For large files, use Ctrl+A in the browser tab or in your editor to ensure nothing is left out.
3
Paste into FixTools and expand
Open FixTools CSS Unminifier, paste the minified CSS into the input panel, and click Unminify. The tool expands every compressed rule block, placing selectors, declarations, and closing braces on separate lines.
4
Read the expanded output
Scan the formatted output to understand the full stylesheet structure. Use your browser or editor search functionality to locate specific selectors or properties within the now-readable content.

Real-world examples

Common situations where this approach makes a real difference:

Learning from a production stylesheet

A junior developer wants to understand how an experienced team structured their CSS architecture. They open the team's production site, extract the minified stylesheet from DevTools, and convert it to readable form. The expanded CSS reveals the team's selector naming conventions, their approach to responsive breakpoints, and the range of custom properties they use. This provides more practical learning than any tutorial, since it is real-world code applied to a working product.

Auditing a client site before redesign

A designer-developer preparing a redesign proposal needs to understand the scope of the existing CSS. They convert the production stylesheet to readable form and count the number of distinct selectors, the number of unique colour values, and the number of breakpoints. This audit informs both the redesign scope estimate and the CSS architecture decisions for the new build.

Identifying the source of an unexpected colour

A developer notices that a button is rendering in a slightly different shade of blue than specified. They convert the production stylesheet to readable, search for the button's class name, and find three different rules targeting it with different background-color values. The readable output makes the cascade conflict immediately visible, and they resolve it by increasing the specificity of the correct rule.

Understanding a legacy codebase before adding features

A team is tasked with adding a new feature to a product built five years ago. The CSS is minified in the build output and the original source files are in an unmaintained preprocessor format. They convert the minified CSS to readable, search for the components adjacent to their new feature, and understand the existing patterns before writing any new CSS. This prevents introducing conflicting selectors or duplicating existing utility classes.

Pro tips

Get better results with these expert suggestions:

Use the readable output to audit value consistency

After converting a large minified stylesheet to readable form, search for specific property names like font-size or padding to see every value used across the entire stylesheet. Inconsistent values are easy to spot in a vertical list of declarations. This audit is impractical in minified CSS but straightforward in readable output.

Identify selector specificity more easily in readable form

Specificity conflicts are easier to reason about when you can read the full selector on its own line. In minified CSS, selectors are concatenated with their declaration blocks, making it hard to identify how many class names, IDs, or pseudo-classes a selector contains. The readable output puts selectors on dedicated lines where you can count specificity components at a glance.

Expand and then search for overriding rules

If an element is styled by two rules and you are not sure which wins, convert the stylesheet to readable, search for every rule that targets the element's class or element type, and compare specificity. Properties that appear multiple times in the readable output indicate potential cascade conflicts that may not be obvious from DevTools alone.

Watch for important annotations after expansion

Minifiers preserve !important annotations since they affect cascade behaviour. After converting to readable, search for !important to find any declarations that were added with that flag. These declarations override normal cascade rules and are a common source of mysterious styling behaviour, especially in stylesheets that evolved over many years.

Look for merged shorthand properties in the readable output

When the readable output shows shorthand properties like border, margin, or padding as single declarations, the original source may have used multiple longhand properties. If you plan to edit specific sides of a margin or a specific border property, expand the shorthand back to longhands to avoid accidentally changing values you did not intend to modify.

Check hex colours against your design tokens

Minifiers shorten hex colours to their three-character equivalents where possible. After converting to readable, compare colour values against your design system tokens. If a colour appears as #e0e0e0 in the readable output but your token is named --gray-200, confirm the hex matches your token definition.

Zero values without units are valid CSS

Minifiers remove units from zero values: 0px becomes 0. This is valid CSS behaviour. When reading the converted output, zero values without px or rem units are intentional and correct, not a bug introduced by the conversion.

FAQ

Frequently asked questions

Minifiers convert six-digit hex colours to three-digit equivalents wherever possible. The colour #aabbcc becomes #abc and #ffffff becomes #fff. This is a valid CSS transformation because both forms describe the same colour. The conversion is applied during minification, not during the conversion to readable form. When you convert minified CSS to readable, you see the already-shortened hex values from the minified file, not your original source values. If you need to match the output against your design tokens, check both the three-digit and six-digit forms of each colour.

Yes. CSS custom properties, declared as --property-name: value and referenced with var(--property-name), are preserved exactly by minifiers and restored exactly by the conversion to readable form. The variable names, their declared values, and their var() references in rule declarations are all reproduced in the readable output. One exception: if the minifier resolved var() calls by inlining the variable values (some aggressive build configurations do this), the readable output will show the inlined values rather than the var() references.

Before conversion, a typical minified stylesheet looks like a single long line or a few lines of dense text: .container{max-width:1200px;margin:0 auto;padding:0 16px}.header{display:flex;align-items:center;height:64px} and so on. After conversion, each rule appears as a block with the selector on its own line, each property on an indented line below, and the closing brace on its own line, separated from the next rule by a blank line. A minified file that was 8,000 characters might become 200 lines of formatted CSS.

Yes. SCSS and Less are compiled to standard CSS before being minified. The minified output does not contain any SCSS or Less syntax: variables are resolved, mixins are inlined, and nesting is flattened into standard selectors. When you convert that minified CSS to readable form, you see the compiled standard CSS, not the original SCSS or Less. Selector names, property values, and structure reflect the compiled state, not the preprocessor source.

Yes. Several value transformations are one-way. Zero values have units removed: 0px becomes 0 and stays 0 in the readable output. Hex colours shortened to three digits stay as three digits. Keyword values may be normalised: initial and inherit applied redundantly may be removed. Longhand properties that were combined into shorthand stay as shorthand. These transformed values are semantically identical to the originals, but they do not look exactly like the source code. The conversion restores only whitespace, not these optimised value representations.

The @charset declaration, typically @charset "UTF-8", must appear as the very first thing in a CSS file if present. Minifiers preserve it in that position. When you convert the file to readable, the @charset declaration appears on the first line, followed by the rest of the formatted rules. You do not need to do anything special to handle it. Note that if the @charset declaration is missing from the minified file, the browser defaults to UTF-8 for modern CSS, so its absence is not typically a problem.

Yes. Sass compiled with the compressed output style produces minified CSS that is syntactically identical to CSS minified by a separate tool. The conversion to readable form works the same way regardless of whether the compression was applied by cssnano, clean-css, or Sass's own compressed output mode. All of these produce standard CSS token streams with whitespace removed, and the conversion restores whitespace to all of them.

The conversion restores all structural whitespace, making the CSS fully readable, but it is not a perfect reconstruction of the original source. Information lost during minification, including comments, the original authoring whitespace style (two-space vs four-space indentation), blank lines used to group related rules, and any value representations that were optimised, cannot be recovered. The readable output is functionally equivalent and human-readable, but it represents the minifier's optimised form of the code rather than the author's original form.

Vendor prefixes show up as ordinary property tokens in the readable conversion: each -webkit-, -moz-, or -ms- variant appears on its own indented line, typically followed by the unprefixed standard property. The readable output makes them easy to audit because the prefix tokens become searchable. The relevant question is whether each prefix is still needed for any browser you support. Autoprefixer driven by a modern Browserslist target trims obsolete prefixes automatically, but legacy bundles often carry years of accumulated prefixes that no current browser requires. Searching the readable output for -webkit- and cross-referencing each match against current browser usage data lets you identify safe removals at the source level. A typical legacy stylesheet sheds three to eight percent of its weight after a careful prefix audit.

No. Source maps record column and line offsets in the minified file, and the conversion shifts every offset by adding whitespace. The original .css.map remains valid for the original minified file in DevTools, but pointing it at the readable conversion will produce wrong mappings. The two artifacts serve different workflows. If the original build emitted a source map and it is still reachable, prefer DevTools with the map attached because it shows the authored source including comments and original variable names, which is higher fidelity than any conversion. If the map is absent, has been stripped for production hardening, or returns 404, the readable conversion is the right tool. Treat the conversion as a standalone artifact rather than a partner to the source map.