Free · Fast · Privacy-first

Expand Compressed CSS from Themes and Templates

WordPress themes, email templates, and commercial CSS frameworks distribute their stylesheets as compressed files to reduce download size.

⚡

Expands WordPress theme CSS, email template styles, and third-party frameworks

🔒

Reveals property values needed for writing accurate overrides

✨

Handles any valid compressed CSS regardless of its source

⚡

Browser-based: paste and expand instantly, 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.

Reading Compressed Third-Party CSS Before Making Customisations

WordPress themes distribute their main stylesheet as a style.css file in the theme directory. Premium themes often minify this file to reduce page load time. When a site owner or developer wants to customise the theme without creating a child theme, they need to understand what styles the theme applies. Expanding the compressed style.css in FixTools takes seconds and reveals the full structure: which class names the theme uses, what font sizes and colours it sets, how its grid and layout rules work, and which elements it targets with universal or element-type selectors. This context is essential for writing overrides that work predictably.

Email templates present a different compression scenario. HTML email requires all CSS to be inlined into style attributes because most email clients do not support external stylesheets or even style blocks. Email builders and template systems often generate highly compact inline styles by concatenating all declarations with minimal whitespace. When you need to read or edit the CSS of an existing email template, expanding those compact declarations helps you understand what is being applied before making changes. Expanding the template CSS also reveals patterns like repeated font declarations that could be consolidated.

Commercial CSS frameworks like Bootstrap, Foundation, and Bulma distribute minified CSS as their production-ready asset. When you want to override framework defaults intelligently rather than bluntly, you need to see the exact property values the framework uses. Opening the CDN URL of the framework stylesheet gives you the minified content. Expanding it reveals default values, the specificity of each rule, and the naming conventions used for component classes. This knowledge lets you write overrides that target the exact specificity and property you need to change, avoiding the overuse of !important.

Third-party themes and templates frequently arrive with extensive vendor-prefixed CSS because they were built to support a wide browser range. Once expanded, the prefix profile is a useful diagnostic for how recently the theme was authored or rebuilt. A theme containing many -webkit-, -moz-, and -ms- variants of properties like border-radius, box-shadow, and transform was likely compiled with an older Autoprefixer configuration targeting browsers that no current user is running. When you write your override stylesheet for a child theme or template customisation, you can usually skip the prefixes entirely and rely on the standard property; modern browsers handle the unprefixed form natively. Including obsolete prefixes in your overrides adds maintenance weight without any user-visible benefit. The expanded theme CSS makes the prefix audit fast because each prefixed property is on its own searchable line rather than buried in a one-liner.

MDN Web Docs: Cascade, Specificity, and Inheritance WordPress Developer Resources: Child Themes

How to use this tool

💡

Paste compressed CSS from a WordPress theme's style.css, an email template's inline or embedded styles, or any third-party stylesheet. The expanded output shows every rule in readable, indented form so you can understand the existing styles before making customisations.

How It Works

Step-by-step guide to expand compressed css from themes and templates:

1
Locate the compressed stylesheet
For a WordPress theme, view the page source and find the link tag for style.css. Open that URL directly. For an email template, locate the CSS in the template file's style block or inline attributes. For a framework, open its CDN URL directly in a browser tab.
2
Copy the compressed CSS content
If viewing in a browser tab, use Ctrl+A to select all, then Ctrl+C to copy. If accessing via a file manager or FTP, open the file and copy all content. Ensure the full file is copied, not a partial selection.
3
Expand in FixTools
Open FixTools CSS Unminifier and paste the compressed CSS into the input panel. Click Unminify. The output shows the full stylesheet with each rule on its own formatted block.
4
Read and write informed overrides
Use the expanded output to understand the exact property values, selectors, and specificity of the rules you want to customise. Write your override rules with correct selectors and specificity based on what you read in the expanded CSS.

Real-world examples

Common situations where this approach makes a real difference:

Customising a premium WordPress theme

A site owner purchased a premium WordPress theme and wants to change the primary button colour and font size. The theme stylesheet is minified. They expand it with FixTools and search for the button class name. The expanded CSS reveals that buttons are styled with .theme-btn using a background-color and font-size, and that the rule also applies to anchor tags with the same class. They write a child theme override targeting the same selector with the new values, and the customisation applies correctly across all button instances.

Reading an email template before editing

A marketing team member needs to change the header background colour in a purchased HTML email template. The template uses compact inline styles throughout. They extract the style block from the template head, expand it with FixTools, and identify that the header background is set in a .header class rule. They update the colour value and re-compact the styles. The email renders correctly in Outlook, Gmail, and Apple Mail after the change.

Overriding Bootstrap 5 defaults without !important

A developer building on Bootstrap 5 wants to change the default border radius for cards. Instead of using !important, they open the Bootstrap CDN CSS, expand it with FixTools, and search for .card. The expanded output shows that Bootstrap uses .card { border-radius: var(--bs-card-border-radius) } with the variable defined in :root. They override --bs-card-border-radius in their own stylesheet's :root block, which changes the value globally without needing !important or a high-specificity selector.

Understanding a Tailwind base CSS file

A developer new to Tailwind wants to understand what Tailwind's base layer applies before their component styles. They open the generated CSS bundle, expand it with FixTools, and scroll to the beginning. The expanded output shows Tailwind's preflight reset: a large set of base styles applied to HTML elements. Understanding these resets helps the developer predict why their form inputs and headings look different from browser defaults, and which properties they need to explicitly set to achieve their desired appearance.

Pro tips

Get better results with these expert suggestions:

Find the WordPress theme CSS URL from the page source

Right-click on a WordPress page and choose View Page Source. Search for style.css or the theme name to find the link tag that loads the theme stylesheet. The href attribute gives you the direct URL. Open that URL in a new tab to get the raw CSS content, which you can then copy and paste into FixTools for expansion.

Expand both the theme CSS and your override CSS for comparison

After writing your customisations, expand both the original theme CSS and your override CSS side by side. Confirm that your override rules have higher specificity than the theme rules they are intended to replace. This side-by-side comparison in readable form prevents the common mistake of writing an override with insufficient specificity that gets silently ignored.

Identify responsive breakpoints in the expanded theme CSS

After expanding a theme stylesheet, search for @media to find all breakpoints. Note the exact pixel values the theme uses (768px, 992px, 1200px, etc.) and match those values in your override CSS. Mismatched breakpoints are a common cause of responsive overrides that work at one viewport width but fail at another.

Look for CSS custom properties in modern theme CSS

Modern WordPress themes and CSS frameworks define their colour palette, typography scale, and spacing values as CSS custom properties in a :root block. After expanding, find this block and read the variable names. Overriding the custom property value in your child theme stylesheet is more efficient than overriding each individual property that uses the variable.

Use a child theme for WordPress customisations, not direct edits

After expanding the theme CSS to understand the structure, write your customisations in a child theme stylesheet rather than editing the parent theme directly. Child theme styles are preserved when the parent theme updates, and the parent theme CSS is still loaded, so your overrides only need to address the specific values you want to change.

Search for specific hex colours to find all colour-related rules

After expanding a theme stylesheet, use Cmd+F to search for a brand colour hex value to locate all rules that set that colour. This is more reliable than searching for colour property names, since a theme may apply the same colour via background-color, border-color, fill, and other properties.

Note the CSS specificity before writing overrides

Read the selectors in the expanded CSS carefully before writing overrides. If the theme uses .container .btn as a selector (two classes), your override needs equal or higher specificity to win. An override with just .btn alone will lose. The expanded CSS makes this specificity analysis possible in a way that minified CSS does not.

FAQ

Frequently asked questions

Right-click the page and select View Page Source. Search for .css in the source to find all stylesheet link tags. The main theme stylesheet is usually referenced as /wp-content/themes/theme-name/style.css. Copy that relative URL, combine it with the site domain, and open it in a new browser tab. You will see the raw CSS content. If the theme loads a separate minified file, it may be named style.min.css. Check the link href attribute for the exact filename. Some themes also load CSS via wp_enqueue_style with version query strings appended.

Always use a child theme for WordPress CSS customisations. Direct edits to a parent theme stylesheet are overwritten every time the theme updates. A child theme stylesheet is never overwritten by theme updates. After expanding the parent theme CSS to understand the structure, create a child theme with its own style.css that imports the parent and adds your overrides. The child theme styles load after the parent styles, so any declaration in the child theme with equal or higher specificity will override the parent.

Email templates using only inline styles have no selector-based CSS. Each HTML element has a style attribute with compact declarations. To expand a specific element's inline style, copy the value of the style attribute (not including the style= and the surrounding quotes) and paste that into FixTools. The tool will expand each declaration onto its own line. For a template with dozens of elements, expand the inline styles of the elements you need to modify rather than trying to expand the entire template at once.

Yes. Page builders generate CSS as standard CSS syntax, even if it is compact or minified. Elementor and Divi generate CSS with class names like .elementor-widget-container and .et_pb_column that are minified like any other CSS. Open DevTools, find the CSS generated by the page builder in the Network tab, copy the response, and expand it in FixTools. The readable output shows the exact classes and values the page builder applied.

For Bootstrap, prefer overriding CSS custom properties (CSS variables) in your own :root block. Bootstrap 5 defines most visual values as variables, and overriding the variable changes the value everywhere it is used. For Tailwind, configure values in tailwind.config.js before the build rather than overriding the generated CSS. If you need a post-build override, expand the framework CSS to find the exact selector and specificity, then write a targeted override in your own stylesheet with equal or higher specificity.

Yes. WooCommerce loads its own CSS via wp_enqueue_style. The WooCommerce CSS files appear in the DevTools Network tab just like theme CSS files. They are often minified. Common files include woocommerce.min.css and woocommerce-layout.min.css. Expand any of them in FixTools to read the rules. WooCommerce class names follow a predictable pattern (.woocommerce, .wc-*, .cart, .checkout) making them easy to search in the expanded output.

Modern WordPress installations use version query strings on stylesheet URLs (for example, style.css?ver=2.3.1). When you open that URL directly or copy it from DevTools, check the URL for a query string. The version number in the URL corresponds to the theme version. You can cross-check this against the theme version in the WordPress admin dashboard. If you are seeing an old version, clear your browser cache (Ctrl+Shift+Delete) and reload with DevTools open and Disable Cache checked.

Reading CSS for the purpose of understanding how to write overrides for your own website is generally permitted. CSS applied to your own pages is visible to any user with a browser and DevTools, so reading and understanding it is normal and legitimate. Commercial theme licences may restrict redistribution of theme files. Expanding and reading the CSS to write customisations for the site you licensed the theme for is not redistribution. If you are uncertain about a specific licence, consult the theme's licence terms directly.

Use the FixTools expander for the first read and any one-off inspection. It runs in your browser without install, config file, or Node version matching, and it handles the full range of minified CSS including vendor prefixes, custom properties, and merged selector groups. Use Prettier when the theme CSS is going to become part of a project you actively maintain: install Prettier, configure printWidth and tabWidth to match your repo, and let it format on save. The expander is optimised for inspection; Prettier is optimised for ongoing authoring. The honest workflow for most theme customisation tasks is to expand once with FixTools to understand the structure, write your child theme overrides in a separate file managed by Prettier, and leave the original theme stylesheet untouched so theme updates do not overwrite your work.

The original .css.map remains valid for the original minified file, not the expanded copy. Expanding shifts every line and column offset by adding whitespace, so the map no longer aligns with the expanded text. If you primarily need to debug the theme in the browser, work from the minified file with the map attached and let DevTools show the authored source in the Sources panel; that is higher fidelity than expansion because it includes comments and original variable names. If the map was stripped by the theme author for distribution, the expanded output is the right standalone artifact. Theme distributions rarely include source maps because the maps would expose the authoring structure that the theme vendor often wants to keep private. Check the bottom of the minified file for a sourceMappingURL comment to know which path is available.