Free · Fast · Privacy-first

Unminify CSS for Debugging Live Site Issues

A visual bug appears only in production.

⚡

Expands production CSS so you can search for specific selectors and properties

🔒

Enables line-by-line comparison against your source CSS to find discrepancies

✨

Identifies rules that were merged, altered, or incorrectly included by the build

⚡

Browser-based: instant expansion with no tools to install

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.

Using Unminified Production CSS to Locate Visual Bugs

Production-only visual bugs fall into a small set of categories. The most common is a build pipeline that applied an unwanted transformation: cssnano merged two rules that should have been separate, a PostCSS plugin modified a value, or a concatenation step included an extra stylesheet that overrides a rule. The second category is a deployment issue: a cache-busting failure means the browser is loading an old version of the CSS. The third is a source-level error that is invisible in development but visible in production because the development environment applies default styles that production does not. Unminifying the production CSS helps diagnose the first two categories and provides evidence for the third.

The debugging workflow starts with extracting the production CSS from Chrome DevTools Network tab with Disable Cache enabled. Pasting it into FixTools and clicking Unminify takes under a second. Now you have two readable files: the unminified production CSS and your source CSS. Open both in a text editor or diff tool. Search for the class name or property involved in the visual bug. Compare the production rule against the source rule. Differences between them are your bug candidates: a changed value, a merged selector, an extra declaration, or a missing declaration are all visible in a readable diff but invisible in a minified diff.

When the production and source rules look identical, the bug category is likely a specificity conflict or a cascade ordering issue. In the unminified production CSS, search for every rule that targets the selector in question. The production CSS concatenation order determines cascade precedence for equal-specificity rules: a later rule overrides an earlier one. Your source files may have been concatenated in a different order than you expected, causing a rule that was harmless in development to override another rule in production. Reading the full unminified CSS in order reveals this kind of ordering conflict in a way that the DevTools Styles panel alone cannot.

Before reaching for the unminifier, always check whether a source map is reachable. Scroll to the bottom of the production CSS in the Network tab response and look for a sourceMappingURL comment. If the referenced .css.map file loads when you fetch it directly, attach it via DevTools and the Sources panel will show the authored source including comments, original variable names, and the file path each rule came from. That is strictly higher fidelity than unminification because it shows what the developer actually wrote rather than what survived minification. Production builds often strip or 404 the map for security and bandwidth reasons; when that happens, unminification is the right alternative. The decision should be deliberate per debugging session because the map answers questions (which source file, which original class name) that unminification cannot recover. Treat the two as complementary tools rather than substitutes.

Chrome DevTools: CSS Debugging Reference MDN Web Docs: Debugging CSS

How to use this tool

💡

Paste minified production CSS from your site's Network tab response. The expanded output makes every selector and property searchable and comparable against your source, turning an opaque production file into a readable debugging artifact.

How It Works

Step-by-step guide to unminify css for debugging live site issues:

1
Reproduce the bug and identify the element
Open the live production site in Chrome. Reproduce the visual bug. Open DevTools with F12, click on the affected element in the Elements panel, and note the class names applied to it. These are the selectors you will search for in the unminified CSS.
2
Extract the production CSS with cache disabled
Click the Network tab in DevTools. Check Disable Cache. Reload the page with Ctrl+R. Find the main CSS bundle in the Network tab, click it, and copy the full Response body. This is the exact CSS your browser is applying.
3
Unminify and search for the relevant selector
Open FixTools CSS Unminifier, paste the production CSS, and click Unminify. Copy the output to a text editor. Search for the class names you noted from the Elements panel. Read every rule that targets the affected element.
4
Compare against source CSS and identify the discrepancy
Open your source CSS alongside the unminified production CSS. Find the same selector in both files. Compare the declarations line by line. Any difference in property values, order, or selector grouping between the two files is a candidate for the root cause of the visual bug.

Real-world examples

Common situations where this approach makes a real difference:

Finding a navigation height regression after a deployment

After a deployment, the navigation bar is 8px taller on the live site than on the developer's local machine. The developer extracts the production CSS, unminifies it, and searches for the navigation class. The unminified output shows that the navigation rule in production has padding: 16px 24px while the source has padding: 8px 24px. Tracing back through the build history reveals that a branch merge introduced a duplicate rule, and the build pipeline's cssnano kept the later version. The developer removes the duplicate from the source and the fix deploys correctly.

Diagnosing a font colour discrepancy between environments

An article page uses a dark grey text colour in development but renders with a lighter grey in production. The developer opens the production site, extracts the CSS, and unminifies it. Searching for the article body class reveals two rules targeting it in the production CSS: one from the base stylesheet and one from a third-party analytics widget stylesheet that was recently added. The widget stylesheet loaded after the base stylesheet and overrides the colour. The developer increases the specificity of the article body rule to resolve the override.

Locating a mobile-only layout break

A product card grid layout works correctly at desktop width but breaks at 480px viewport width, showing a single column instead of two columns. The developer unminifies the production CSS and searches for the @media (max-width: 480px) block. The unminified output shows that inside the mobile breakpoint, the grid-template-columns property is overridden to 1fr. Tracing back, a utility class that was applied to the grid container sets this value. The developer removes the utility class from the HTML and the two-column layout is restored.

Proving that a CSS hotfix reached production

A developer deployed a CSS hotfix during an incident and needs to confirm it is live before resolving the incident ticket. They extract the production CSS with cache disabled, unminify it, and search for the specific property and selector from the hotfix. Finding the correct value in the unminified output confirms the hotfix is deployed and active. The incident ticket is closed with the unminified CSS excerpt as evidence that the fix is in production.

Pro tips

Get better results with these expert suggestions:

Diff the unminified production CSS against the unminified source CSS

Unminify both the current production CSS and your development source CSS, then run a diff between the two formatted files. The diff output shows exactly which lines differ between what you intended to ship and what is actually in production. This is the most direct path to identifying build pipeline discrepancies and is far more actionable than comparing minified files.

Use DevTools Coverage to identify unreachable overrides

After unminifying, the readable CSS helps you understand the structure. But understanding which rules actually execute requires DevTools Coverage. Open Coverage, interact with the page to reproduce the bug, and check which rules are marked as unused. An override rule marked as unused may indicate that it is being applied after a rule that already wins the cascade, or that it targets a selector that no element on the page matches.

Check @media query breakpoints for mobile-specific bugs

After unminifying, search for @media to locate every breakpoint block. If the bug is visible on mobile, find the mobile breakpoint (max-width: 768px or similar) and read every rule inside it. Production CSS concatenation sometimes changes the order of media query blocks relative to base styles, affecting which rules override which at specific viewport widths.

Look for specificity-boosting patterns in the unminified output

After unminifying, search for patterns like html body, #app ., or :root to find selectors with artificially boosted specificity. These high-specificity selectors are common in third-party stylesheets and legacy code. If one of these selectors targets the same element as your rule, it will win the cascade regardless of source order. The unminified CSS makes these patterns visible and searchable.

Always use Disable Cache when extracting production CSS

Before copying production CSS from the Network tab, check the Disable Cache box in DevTools. A cached stylesheet may be days old. Without disabling cache, you may unminify the wrong version of the CSS and spend time debugging a file that is not what the browser is currently using.

Search for the bug's selector, not just the property

After unminifying, search for the full selector that targets the buggy element, not just the property name. The property may appear in dozens of rules. Searching for the specific selector narrows your focus to the handful of rules that directly affect the element, making the comparison faster.

Check rule count before and after your fix

Count how many times a selector appears in the unminified production CSS. If the same selector appears more than once, there is a cascade conflict. After applying your fix, unminify the new production build and confirm the selector count is what you expect.

FAQ

Frequently asked questions

Production-only bugs typically stem from differences in the CSS pipeline. In development, you may serve individual CSS files in a specific order, while the production build concatenates them in a different order. Development may use unminified CSS where comments are visible and declarations are separate; production minification may merge rules or apply value transformations. Development may serve files from localhost where browser caching behaves differently. Unminifying the production CSS and comparing it to your development CSS directly surfaces these differences, which are the most likely causes of environment-specific bugs.

Open DevTools Network tab and check the Status column for the CSS file request. A status of 304 Not Modified or a from disk cache annotation in the Size column indicates a cached response. Check the Response Headers for Cache-Control and Expires values to understand the cache lifetime. To bypass the cache, enable Disable Cache in DevTools and reload. If the bug disappears after bypassing the cache, the cached file is the problem. Either the server's cache headers are too aggressive or the build deployment did not properly invalidate the old CSS cache.

Unminify the production CSS with FixTools, save the output as production.css. Open your source CSS file as source.css. Open both files in VS Code and run the built-in Diff Editor: press Ctrl+Shift+P, type Open Diff, and select both files. The diff view highlights every line that differs between the two formatted files. Alternatively, paste both files into the FixTools Diff Checker for a browser-based comparison without needing a local editor.

Source maps are better when available because they show you the original source file exactly as you wrote it, including comments and your formatting style. When source maps are configured, DevTools shows the original file in the Sources panel. However, source maps are not always deployed to production for security reasons (they expose your source code structure). When source maps are absent, unminifying the production CSS is the alternative debugging approach.

First confirm the bug is CSS-related by inspecting the element in the affected browser's DevTools. Look for properties that are crossed out in the Styles panel (indicating they are overridden or invalid). Extract the CSS from that browser's Network tab, unminify it, and compare it against what another browser receives. Different browsers may cache different versions of your CSS, or a vendor-prefixed property may behave differently. The unminified output from the specific browser is the ground truth for that browser's rendering context.

If the CSS content is identical, the bug is likely caused by cascade ordering (source order within equal-specificity rules matters), specificity conflicts with another stylesheet on the page (a third-party script or browser extension may be injecting CSS), or inherited styles from parent elements. Check the DevTools Computed tab for the affected element, which shows the final computed value of every property with its origin. This shows you which rule won the cascade and where it came from, pointing you toward a rule that may not be visible in your own stylesheets.

Yes, when debugging a regression. Saving a dated unminified snapshot (production-2024-03-15.css, for example) gives you a baseline to compare against future deployments. If a new bug appears after a subsequent deployment, unminify the new production CSS and diff it against the snapshot. The diff immediately shows what changed between the two versions, which is often the direct cause of the new bug.

Yes. CSS linters like Stylelint accept any valid CSS as input. Unminifying the production CSS and running a linter over the output can reveal rule violations, deprecated properties, or specificity patterns that your development CSS does not show because the development files are organised differently. The linter will report issues using line numbers in the unminified output, which you can then trace back to the corresponding selector in your source CSS.

Vendor prefixes are a common source of environment-specific bugs because their behaviour can diverge between browsers and between prefix variants. After unminifying, search for the prefix tokens on the property involved in the bug. Sometimes Autoprefixer emits a prefixed variant whose syntax differs subtly from the standard property (the old flexbox -webkit-box model is a classic example), and the prefixed variant wins in a browser that should be using the standard form. The unminified output makes this visible because each prefixed variant is on its own line. If the bug only appears in one browser, also check the cascade order of the prefixed and unprefixed variants; the unprefixed standard property must come last for modern browsers to use it. Reordering the variants in your source typically resolves the issue.

Yes, this often produces the most useful diff. Prettier produces deterministic output that eliminates whitespace noise from the comparison, so any remaining differences are real content changes rather than formatting quirks. The workflow is: unminify the production CSS with FixTools and save it as production.css, run Prettier on your source file to produce a formatted source.css with the same indentation and brace style as the unminified output, then diff the two formatted files. Real differences become obvious because the formatting baseline is consistent on both sides. Without this normalisation step, a diff between unminified production CSS (two-space indent, predictable structure) and a raw source file (possibly using four-space indent or different brace conventions) shows whitespace changes on every line and buries the actual content differences.