Free · Fast · Privacy-first

CSS Bundle Inspector

Production websites deliver CSS as minified bundles: single compressed files that may contain a framework, component library, and application styles all concatenated together.

⚡

Step-by-step workflow for extracting CSS from DevTools Network tab

🔒

Converts concatenated multi-file bundles to readable code

✨

Works on bundles from any framework: React, Angular, Vue, plain HTML

⚡

Instant browser-based conversion, no install 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.

How to Extract and Read a Production CSS Bundle

A CSS bundle is the output of a build tool that has concatenated multiple source CSS files, processed them through PostCSS or a preprocessor, and minified the result. The bundle may be named main.css, bundle.min.css, or a content-hash filename like styles.a1b2c3d4.css. It is served from the production server or a CDN and loaded by the HTML via a link tag. When you open DevTools Network tab while the page loads, this bundle appears as a CSS request. Clicking the request and viewing the Response sub-tab shows the raw minified content exactly as it arrived from the server.

The Response sub-tab is the right source for bundle inspection because it shows the actual bytes the browser received. The Sources panel also shows CSS files, but if source maps are configured, it may show the original pre-build source rather than the bundle. Source maps are useful for debugging with the original source context, but for inspecting what is actually deployed to production users, the Network tab Response is the ground truth. Copy the entire response body and paste it into FixTools to convert it to readable form.

After converting, the bundle's structure becomes clear. You will typically see a CSS reset or normalize block near the beginning, followed by base element styles, component-level styles, and utility classes. In frameworks like Next.js, the bundle may interleave styles from multiple components in the order they were imported. Understanding the bundle structure helps you locate specific rules more quickly and understand the cascade order, since rules later in the file override earlier rules of equal specificity.

Indentation conventions deserve a deliberate decision when the converted bundle is going to live in a code review or a documentation deliverable. The converter outputs two-space indentation, matching Prettier and most modern style guides. That works well for inspection: deeply nested @media inside @supports blocks remain readable without horizontal scrolling, and bundle structure is easier to follow at modest indent depths. If the converted file will be committed alongside a codebase that uses four spaces or tabs, re-indent before commit using Stylelint's indentation rule, Prettier with a project-specific tabWidth, or the editor Convert Indentation command. The cost of a mismatched indentation style is not just aesthetic; it triggers reformat-on-save in many editors, which then mixes the indentation flip with whatever real change a future developer is trying to make, producing diffs that are hard to review.

Chrome DevTools: Network Features Reference MDN Web Docs: HTTP Caching

How to use this tool

💡

Paste a production CSS bundle copied from the browser DevTools Network tab Response sub-panel. The output expands the entire concatenated bundle into readable, indented CSS showing every rule from every file that was combined into the bundle.

How It Works

Step-by-step guide to css bundle inspector:

1
Open DevTools and disable cache
Press F12 to open Chrome DevTools. Click the Network tab. Check the Disable Cache checkbox. This ensures the page reloads the current production bundle from the server rather than serving a cached version.
2
Reload and locate the CSS bundle
Press Ctrl+R to reload the page. Click the CSS filter in the Network tab. Identify the main bundle by file size: it is usually the largest CSS file. Click the bundle filename in the request list.
3
Copy the response body
Click the Response sub-tab in the request detail panel. Click inside the response text area and press Ctrl+A to select all, then Ctrl+C to copy the complete minified bundle content.
4
Convert in FixTools and explore
Open FixTools CSS Unminifier, paste the bundle content, and click Unminify. Copy the readable output to a text editor. Use Cmd+F to search for selectors, properties, or at-rules of interest within the converted bundle.

Real-world examples

Common situations where this approach makes a real difference:

Investigating a page-specific CSS regression

A product manager reports that text on a specific product page became smaller after a recent deployment. A developer opens the product page in Chrome, copies the CSS bundle from the Network tab, converts it to readable using FixTools, and searches for the product card class name. The converted bundle shows that the font-size declaration was changed from 16px to 14px in the most recent build. The change is traced to a component style update that was not intended to affect product cards.

Auditing a performance budget for CSS

A performance engineer wants to understand what the CSS bundle contains and whether any large sections can be deferred or removed. They extract and convert the bundle, then walk through the readable output section by section. They identify a large block of @keyframes animations for a feature that was removed from the UI three months ago. Removing those keyframe declarations reduces the bundle size by 12KB, which the engineer confirms against the before-and-after minified file sizes.

Verifying a third-party CSS integration

A team adds a third-party analytics dashboard widget that injects its own CSS bundle. A developer inspects the network requests on the page with the widget enabled and finds a second CSS bundle loaded from the widget's CDN. They copy and convert that bundle to understand what styles it introduces. The converted output reveals that the widget defines its own flexbox layout and custom properties that conflict with the host application's grid system, explaining the layout shift they observed after adding the widget.

Documenting production CSS for a handoff

A contractor is handing off a project and the client wants documentation of the current production CSS. The contractor extracts the production CSS bundle from the live site, converts it to readable, adds structural comments identifying the sections, and delivers the formatted file as part of the handoff package. The client team can read and maintain the formatted file without needing the full build toolchain.

Pro tips

Get better results with these expert suggestions:

Identify bundle boundaries within a concatenated file

Build tools that concatenate multiple files sometimes insert comments as file boundaries before minifying. If the minifier was configured to preserve licence comments (starting with /*!), these boundary comments survive in the bundle. After converting to readable, search for /*! to find these markers. They identify which section of the bundle originated from which source file.

Check the Content-Length header to confirm bundle size

In the DevTools Network tab, click the bundle request and check the Headers sub-tab for the Content-Length response header. This tells you the exact transfer size of the minified bundle in bytes. Comparing this against the character count of the converted readable output helps you understand the whitespace overhead.

Use multiple Network tab CSS entries to identify split bundles

Some build configurations split CSS into multiple bundles: a critical CSS file loaded in the head and a deferred bundle loaded asynchronously. Both appear in the Network tab. Inspect and convert each one separately to understand the full CSS loaded on a page.

Look for duplicate @font-face declarations in the converted bundle

Concatenated bundles sometimes include @font-face declarations from multiple component stylesheets that define the same font. After converting, search for @font-face and count the occurrences. Duplicate font face declarations add bundle size without providing any additional functionality.

Disable cache before inspecting to see the latest bundle

Check the Disable Cache checkbox in the DevTools Network tab before reloading. Without disabling cache, Chrome may serve a cached version of the CSS bundle that could be days or weeks old, not reflecting recent production changes.

Filter by CSS type to find bundles quickly

Click the CSS filter button in the DevTools Network tab to show only stylesheet requests. Production bundles stand out by their file size: they are typically the largest CSS files on the page. Sort by Size to find the main bundle quickly.

Use Ctrl+Shift+P and type Coverage to find unused CSS

After converting a bundle to readable form, use DevTools Coverage tool to identify which rules are actually used on the page. Cross-referencing coverage data with the readable bundle helps prioritise CSS that can be removed from the bundle in future builds.

FAQ

Frequently asked questions

Open DevTools with F12, click the Network tab, and check the Disable Cache checkbox. Reload the page with Ctrl+R. Click the CSS filter button in the Network tab toolbar to show only stylesheet requests. The main bundle is typically the largest CSS file in the list. Click the Size column header to sort by size and the largest file will appear at the top. Click the filename, then click the Response sub-tab to see the raw minified content.

Chrome DevTools uses source maps when they are available. A source map is a .css.map file that maps minified positions back to original source positions. When a source map is configured and accessible, the Sources panel shows the original pre-minified source. The Network tab always shows the actual bytes delivered to the browser, regardless of source maps. For inspecting what is actually deployed, always use the Network tab Response view rather than the Sources panel.

Yes. DevTools captures all network requests made by the browser, including CSS bundles loaded after authentication. Log into the site, then open DevTools and reload the authenticated page. The CSS bundle requests will appear in the Network tab as normal. The browser's session credentials are automatically included in the requests, so the CSS is delivered in the same way it would be for a logged-in user.

Lazily loaded CSS may not appear in the Network tab until the browser requests it. To capture it, keep DevTools open with the Network tab active and interact with the part of the application that triggers the lazy load (navigating to a specific page, opening a modal, or expanding a component). The CSS request will appear in the Network tab when it is made. You can then copy the response the same way you would for an eagerly loaded bundle.

In a Single Page Application, CSS bundles are typically loaded once during the initial page load. They may also be loaded when navigating to specific routes if the application uses code splitting. Keep the Network tab open, navigate to the route that uses the CSS you want to inspect, and check for any new CSS requests. If the application loads all CSS upfront, the full bundle will appear on the initial page load. Use the Search functionality in DevTools (Ctrl+Shift+F) to search across all loaded files.

A CSS bundle is a single file containing all the CSS for the application or a large section of it. A CSS chunk is one of several smaller CSS files produced when a build tool splits CSS using code splitting or lazy loading. Both are minified production CSS files. For a code-split application, you may see several CSS chunks in the Network tab: one for the initial route and additional chunks loaded when navigating to other routes. Convert each chunk separately and combine the readable outputs to get a full picture of all the CSS in the application.

The converted bundle is readable and syntactically valid, making it a usable starting point for a development stylesheet. However, it represents the compiled output of the build pipeline, not the original source files. It will not have the logical file structure, original comments, or preprocessor features of the source. If you have access to the source repository, use that instead. If not, the converted bundle is your best available starting point for understanding and modifying the CSS.

The converted bundle is larger than the minified bundle because all the whitespace has been reinserted. A minified bundle at 80KB might convert to 300KB or more of readable text. This is the expected size of formatted CSS with proper indentation. The content is identical: every selector, property, and value is the same. If the readable size seems unexpectedly large for the number of styles on the page, the bundle may contain unused rules from components or library features that are not actually used in your application.

Treat the source map as the primary inspection path if it is reachable, and the converted bundle as the fallback when it is not. After locating the bundle in the Network tab, scroll the Response sub-tab to its end and look for a sourceMappingURL comment. Try fetching the referenced .css.map directly. If it loads, DevTools will show the authored source in the Sources panel with original class names, comments, and preprocessor structure intact, which is strictly higher fidelity than any conversion. Many production builds strip or 404 the map for security and bandwidth reasons; in those cases the converted bundle is the right artifact. The mistake is reaching for the conversion habitually without checking for the map first, because the map often exists and answers many questions the conversion cannot.

Yes, the prefix profile is a useful diagnostic. Modern Autoprefixer configured with a recent Browserslist target emits very few prefixes because most CSS features are now widely supported without them. A converted bundle that contains many -webkit-, -moz-, and -ms- variants of common properties usually indicates an older or overly permissive Browserslist configuration that still targets browsers no current user is running. Search the converted output for the prefix tokens, count occurrences, and cross-check against the current Can I Use data for each property. Removing obsolete prefixes from the source by tightening the Browserslist target typically shrinks the next production bundle by three to seven percent. The converted bundle makes this audit practical because the prefixed properties become searchable on their own lines instead of being buried in a one-line blob.