Free · Fast · Privacy-first

Restore CSS Formatting from Production

A visual bug appears on your live site but not in your local environment.

⚡

Converts DevTools-extracted minified CSS into readable code

🔒

Each rule block and declaration restored to separate lines

✨

Works on complete stylesheets and partial extracts equally

⚡

Browser-based: no upload, no server, fully private

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.

Debugging Live Site Issues by Restoring Production CSS

Browser DevTools is the primary tool for investigating CSS on a live site, but it has a limitation: when you click on an element and inspect its styles in the Computed or Styles panel, you see the applied declarations, not the full rule context. To understand why a specific rule wins the cascade, where it came from in the stylesheet, or what other rules exist in the same block, you need to read the full stylesheet. The Sources panel shows you the file, but if it is minified, the entire stylesheet is one dense line. The Network tab gives you the raw response, which is also minified. Restoring formatting to that raw response is the step that makes the production CSS readable.

The workflow for extracting CSS from DevTools is straightforward. Open Chrome or Firefox, press F12, click the Network tab, reload the page, and filter requests by CSS type. Click the stylesheet you want and select the Response sub-tab. You will see the raw minified CSS as the server delivered it. Select all and copy. In FixTools, paste into the CSS Unminifier and click restore formatting. The output is a properly indented copy of the production stylesheet you can now search with Cmd+F, compare line by line against your source, or annotate with notes.

Restoring formatting also helps when extracting CSS from browser extensions, injected styles from analytics scripts, or third-party chat widgets that append their own stylesheets to your page. These stylesheets are often minified and referenced from external CDN URLs. Opening the CDN URL in a new tab gives you the minified content. Restoring its formatting lets you see which rules the external script is adding to your page, which is the first step toward resolving any conflicts with your own styles.

Source maps deserve a deliberate decision before you commit to manual restoration. Many production builds emit a .css.map file alongside the minified CSS and reference it via a sourceMappingURL comment at the bottom of the file. When the map is reachable, DevTools transparently shows the original authored source: comments, original property order, preprocessor structure, and all. That is strictly higher fidelity than any restoration could produce, because restoration only recovers structure that whitespace removal eliminated, while source maps recover the entire authored file. Before pasting into FixTools, scan the last few lines of the minified content for the sourceMappingURL directive. If the referenced map fetches successfully when you visit it directly, use it via DevTools. If it returns 404 or is stripped entirely (a common production hardening choice), restoration is the right fallback. Knowing which path is available saves time on every debugging session.

Chrome DevTools: Inspect and Edit CSS MDN Web Docs: Firefox DevTools CSS Inspector

How to use this tool

💡

Paste minified CSS extracted from your browser DevTools Network or Sources tab into the input panel. The output shows fully formatted CSS with each rule indented and on its own line, ready to search and compare against your source files.

How It Works

Step-by-step guide to restore css formatting from production:

1
Open DevTools and find the CSS request
Press F12 to open Chrome or Firefox DevTools. Click the Network tab. Check the Disable Cache option. Reload the page. Click the Filter bar and type .css or click the CSS filter button to show only stylesheet requests.
2
Copy the minified CSS response
Click the CSS file you want to inspect. Click the Response sub-tab in the request detail panel. Click into the response body text area, press Ctrl+A to select all content, then Ctrl+C to copy the minified CSS.
3
Paste and restore formatting in FixTools
Open FixTools CSS Unminifier. Paste the copied minified content into the input panel. Click the Unminify button. The output panel shows the production CSS with full formatting restored.
4
Search and compare
Copy the formatted output to a text editor. Use Cmd+F to search for selectors, properties, or values related to the bug you are investigating. Compare the formatted production CSS against your source file to identify any discrepancies.

Real-world examples

Common situations where this approach makes a real difference:

Tracking down a production-only layout bug

A developer's local build shows a correct three-column grid layout, but production shows two columns. They open DevTools on the production site, copy the minified CSS from the Network tab, and restore its formatting with FixTools. Searching the formatted output for grid-template-columns, they find the production CSS has a different value than their source file. They trace this back to a build step that overwrote the property during asset concatenation, fixing a bug that had been invisible in local development.

Identifying styles from a third-party chat widget

A support chat widget added to a site is overriding button styles site-wide. The developer inspects the page, identifies the chat script's CSS file in the Network tab, copies the response, and restores formatting with FixTools. The formatted output reveals a wildcard selector * { box-sizing: content-box } that is conflicting with the site's own box-sizing reset. The developer adds a more specific override rule and the conflict is resolved.

Verifying a hotfix reached production

A developer deployed a one-line CSS hotfix to stop a breaking overlap on mobile. To confirm the fix is live before closing the incident, they copy the production stylesheet from the Network tab, restore its formatting, and search for the class name they modified. Finding the correct property value in the formatted output confirms the hotfix deployed successfully without needing to check the CI/CD log.

Extracting styles from a component library for documentation

A design system team needs to document the default CSS properties of a third-party component library they use. They open the library's CDN-hosted minified CSS, restore its formatting, and extract the relevant rule blocks. The formatted output gives them accurate default values to reference in their documentation, ensuring the documented values match what is actually applied rather than what the library's own docs claim.

Pro tips

Get better results with these expert suggestions:

Disable cache before copying from the Network tab

Chrome DevTools has a Disable Cache checkbox in the Network tab that is active when DevTools is open. Check it before reloading the page for your CSS extraction. This ensures you are reading the current production CSS rather than a cached version that might be stale. Stale cached CSS has caused many fruitless debugging sessions where the bug appeared fixed in the file but persisted in the browser.

Use the Coverage tab to find unused rules

Chrome DevTools Coverage tab (open via Cmd+Shift+P and search Coverage) profiles which CSS rules are actually used on the current page. Run Coverage, interact with the page to trigger all visible states, then export the used-rules report. After restoring formatting, you can cross-reference the Coverage report to identify dead rules that are loading but never applied, which is useful for a cleanup pass after debugging.

Check for multiple production CSS files

Complex applications often load several CSS bundles: a framework CSS, a component library CSS, and an app-specific CSS. Each may be minified. If you are debugging a cascade conflict, you may need to restore formatting for two or three files and compare them all. Note which file each rule came from, since the load order determines cascade precedence for rules of equal specificity.

Search for !important after restoring formatting

Production CSS sometimes contains !important declarations that were added to override specificity problems and forgotten. After restoring formatting, do a Cmd+F search for !important in the restored file. Finding unexpected !important declarations often explains why your source-level overrides are not working on the live site.

Use the Network tab, not the Sources tab, for raw CSS

The Sources panel in Chrome DevTools may display a source-mapped version of the CSS file rather than the actual minified content sent over the network. The Network tab Response sub-tab always shows the raw bytes the browser received, which is what you want for accurate production debugging.

Note the request URL before restoring formatting

Record which CSS file URL you copied before restoring formatting. When you find the conflicting rule in the restored output, you will need the URL to identify which stylesheet is at fault and whether it is one you control.

Save the restored file with a descriptive name

Save the formatted output as production-main-YYYY-MM-DD.css with a date in the filename. This creates a dated snapshot you can reference if the issue recurs or if you need to compare against a later version of the production stylesheet.

FAQ

Frequently asked questions

Open DevTools with F12 and click the Network tab. Check the Disable Cache box that appears when DevTools is open. Reload the page. In the request list, click the Filter bar and select CSS to show only stylesheet requests. Click the CSS file you want, then click the Response sub-tab in the right-side detail panel. The raw minified CSS appears as text. Click inside the text area, press Ctrl+A to select everything, then Ctrl+C to copy. This gives you the exact bytes the server sent, unaltered by any source mapping.

The restored CSS contains all the rules in the stylesheet, while the DevTools Styles panel shows only the rules that apply to the currently selected element. The Styles panel also resolves specificity and shows which rules are overridden. The restored full stylesheet will include many more rules than what you see in the Styles panel for any single element. If you are looking for a specific rule that applies to a particular element, use the DevTools Styles panel to identify the selector and property, then search for that selector in the restored CSS to see the full rule context.

If the CSS is hosted on a third-party CDN with CORS headers, Chrome DevTools Network tab will still show the response body for CSS files since stylesheets are fetched without CORS restrictions. You can copy the response body regardless of the CSS origin. The CORS restrictions that affect JavaScript fetch calls do not apply to stylesheet loading or to reading stylesheet content in DevTools.

Yes. Open DevTools, go to the Sources panel, and find the HTML document. Search for the style tag in the source. Copy the CSS content between the opening and closing style tags, not including the tags themselves. Paste that content into FixTools CSS Unminifier. If the embedded CSS is minified, the tool will restore its formatting just as it would for an external stylesheet file.

Yes. Whitespace is a significant portion of CSS file size. A minified stylesheet at 50KB might restore to 180KB of formatted text. The character count can triple or quadruple because each property is on its own line with indentation, there are blank lines between rule blocks, and all the whitespace that minification removed is reinserted. This is entirely expected and does not indicate anything was added to the file. The content is identical; only the formatting characters differ.

Only if the restored CSS is the best source available for that stylesheet. Ideally, version control should hold the original authored source (possibly SCSS or authored CSS) and the minified output should be generated by a build tool. If you have access to the original source, commit that instead of the restored file, since the original has comments, logical organisation, and accurate variable names. If the original source is lost and restoration is the only recovery option, committing the restored file is better than having only the minified version.

Source maps are separate files (with .css.map extension) that map minified line and column positions back to original source positions. Restoring formatting changes the line and column positions, which makes any existing source map invalid for the restored file. If you are working with source maps for debugging, use them in DevTools as intended: they allow DevTools to show you the original source when you click on a rule. The restoration tool is for when you want a standalone readable copy, not for source-mapped debugging workflows.

Yes. Email templates often include minified or manually compacted CSS in style tags or in inline style attributes. Extract the CSS from the style tag contents, paste it into the FixTools CSS Unminifier, and restore formatting. Email CSS is standard CSS syntax (though using a limited subset of properties supported by email clients), so the restoration works the same way. Inline style attributes from email HTML can also be processed by copying just the declaration content without the style= attribute wrapping.

Restoration produces two-space indented output, which matches the prevailing modern convention and the Prettier default. If your team standard differs, treat the restored file as an intermediate artifact rather than a committable source. Paste it into your editor and run the project formatter: Prettier with a printWidth and tabWidth from your .prettierrc, Stylelint with the indentation rule, or VS Code's Format Document command bound to your project settings. The restored CSS gives you a clean structural starting point that any downstream tool can re-indent without ambiguity. The mistake to avoid is committing restored output with one indentation style into a repository that uses another, because the next developer to edit the file will trigger a formatter and produce a noisy diff that mixes their actual change with the indentation flip.

No special handling at the restoration step itself, but the restored file is a good time to audit whether the prefixes are still required. Properties like -webkit-transform, -moz-appearance, and -ms-flex were essential for browser compatibility several years ago but are now unnecessary for any browser still receiving security updates. After restoring formatting, search for the prefix tokens and cross-check each property against the current Can I Use data. Autoprefixer driven by a modern Browserslist target will drop most of them automatically in the next build. Removing obsolete prefixes from the source typically reduces the production CSS size by three to seven percent and improves readability without affecting any user. The restored file makes this audit practical because the prefixed properties become searchable on their own lines.