Free · Fast · Privacy-first

CSS Deobfuscator Online

Build tools that minify CSS sometimes also rename class names.

⚡

Fully reverses whitespace compression to produce readable code

🔒

Preserves all selector names, property values, and at-rules exactly

✨

Sets clear expectations about what class name obfuscation cannot be undone

⚡

Browser-based processing: nothing is sent to a server

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 Whitespace Recovery Restores and What Class Name Obfuscation Does Not

CSS obfuscation is a term that can mean different things depending on context. In the strictest sense, CSS cannot be truly obfuscated the way JavaScript can, because CSS is declarative and every rule must reference real HTML class names or element types. What build tools can do is rename class names during compilation: a human-readable class name like .navigation-menu-item becomes .a4x in the output CSS and in the corresponding HTML. This transformation is applied consistently across both the CSS and HTML files in a single build step. Tools like CSS Modules (in webpack), css-loader's localIdentName option, and some CSS-in-JS frameworks apply this renaming to provide scoped styles.

Whitespace recovery restores every space, newline, and indentation character that the minifier removed. After recovery, a rule like .a4x{display:flex;padding:0 16px} becomes a properly formatted block with .a4x on its own line and each property indented. The class name .a4x is preserved exactly because it is a real class name in the production code: the HTML uses it, the browser matches it, and changing it would break the styles. Recovery cannot substitute the original human-readable name because that information was discarded during the build and exists only in the source map or the original source files.

The practical implication is that whitespace recovery gives you fully readable code that you can search, compare, and reason about, but the class names may be unfamiliar if they were generated or obfuscated. To connect obfuscated class names back to their human-readable originals, you need either the source map (which maps minified class positions to original class names) or the build configuration (which specifies the naming pattern). If you have access to those resources, use them. If you do not, the whitespace-recovered CSS is still useful: you can find the rule that applies a specific visual property and write an override targeting the obfuscated class name directly.

A source map check should be the first step in any deobfuscation workflow, not a fallback. Scroll to the very bottom of the minified CSS file and look for a sourceMappingURL comment. If it points to a .css.map file that loads when you fetch it directly, attach it to DevTools and the Sources panel will show the authored class names alongside the obfuscated ones. This is strictly more informative than any whitespace recovery because the map carries the original naming and file structure that recovery cannot reconstruct. CSS Modules builds in particular emit detailed maps that show component-level original names. When the map has been stripped (a common production hardening choice) or returns 404, recovery is the right alternative path. The decision between map and recovery should be deliberate per file rather than a habit, because the map is often available and forgotten.

MDN Web Docs: CSS Selectors webpack CSS Modules Documentation

How to use this tool

💡

Paste CSS that has been minified or that has obfuscated class names (like .a4x or .b2z). The tool expands all whitespace to produce readable formatted code. Class names appear exactly as the build tool produced them.

How It Works

Step-by-step guide to css deobfuscator online:

1
Copy the minified CSS with obfuscated class names
Open the production site in a browser, go to DevTools Network tab, and copy the minified stylesheet response body. The file may contain short generated class names alongside normal CSS syntax.
2
Paste into FixTools and recover whitespace
Open FixTools CSS Unminifier and paste the copied content. Click Unminify. All whitespace is restored, producing formatted code where each selector and property is on its own line.
3
Search by property value to find rules of interest
If class names are obfuscated, use Cmd+F to search for a known property value or CSS feature (like z-index, position: sticky, or a specific colour) rather than searching for a class name. This locates the relevant rule regardless of how the class name was generated.
4
Note the obfuscated class name for overrides
Once you find the relevant rule in the recovered CSS, copy the obfuscated class name. Use it in your override stylesheet to target the same element. The class name in the recovered CSS is the actual name used in the HTML, so targeting it will work.

Real-world examples

Common situations where this approach makes a real difference:

Overriding styles from a CSS Modules component

A developer needs to override the padding of a button component built with CSS Modules, where the class name in production is something like Button__root--a1b2. They inspect the button in DevTools to find the obfuscated class name, then recover the whitespace of the production CSS and search for that class. The recovered CSS reveals all the declarations applied to that class, giving the developer the full context needed to write a specific override with correct specificity.

Debugging a z-index conflict in a component library

A modal from a third-party component library is appearing behind another modal on the page. Both use CSS Modules with obfuscated class names. The developer cannot read the minified CSS but recognises the obfuscated class names on the modal element in DevTools. They recover the whitespace of the library's CSS, search for z-index, and find two rules both setting z-index values. The recovered code makes the conflict immediately visible and the fix straightforward.

Understanding what a CSS-in-JS solution generates

A developer is reviewing a React application that uses a CSS-in-JS library generating atomic class names. They extract the generated stylesheet from the page, recover its whitespace, and read the structured output. The recovered CSS reveals that each atomic class corresponds to a single CSS property, and many class combinations are used to compose the final appearance of each component. This architectural pattern becomes clear in the recovered readable output in a way that is completely hidden in the minified version.

Writing a browser extension stylesheet override

A browser extension adds custom styles to a specific website. The website uses obfuscated class names that change between deployments. The extension developer recovers the current production CSS whitespace, identifies the structural selectors (element-type selectors and aria attributes) that are stable across deployments, and writes their override rules against those stable selectors rather than obfuscated class names. The recovered CSS enables this analysis.

Pro tips

Get better results with these expert suggestions:

Source maps solve what whitespace recovery cannot

If you need to connect obfuscated class names to original source names, a CSS source map is the tool for the job. Check whether the production CSS has a sourceMappingURL comment at the end of the file. If it does, DevTools will use the source map to show you the original class names and file locations when you inspect an element. Source maps and whitespace recovery solve different problems: use the map for name tracing, use the recovery for readability.

Identify CSS Modules hash patterns in obfuscated names

webpack's css-loader generates class names in the form ComponentName__className--hash (localIdentName default). After whitespace recovery, looking for double underscores and double hyphens in class names confirms the file used CSS Modules. The component name and original class name appear before the hash, giving you partial readable context even without the source map.

Use the recovered CSS to write override rules

If you are writing CSS overrides for a site you do not control, recovering the whitespace makes it easy to find the obfuscated selector and read its full declaration block. Copy the obfuscated class name from the recovered CSS, write your own rule targeting that class with higher specificity, and your override will apply. This approach works for third-party widget overrides and browser extension stylesheet injection.

Distinguish CSS Modules from manual obfuscation

CSS Modules generates consistent hash-based names following a pattern. Manually obfuscated CSS (where a developer deliberately used meaningless class names) produces names that may follow no pattern. If the recovered CSS has names like .a, .b, .c in sequence, a human likely chose them manually. If names have hashes like .btn--a1b2c3, a build tool generated them. The recovery process is identical, but the interpretation of the output differs.

Use DevTools Styles panel to connect obfuscated names to elements

If the CSS uses obfuscated class names, click on the styled element in Chrome DevTools and check the Styles panel. The panel shows which obfuscated class names apply to that element, letting you find the correct rule in the recovered CSS without knowing the original name.

Search recovered CSS by property value, not class name

If class names are obfuscated, searching for them is unproductive. Instead, search the recovered CSS for the property value that is causing the issue, such as z-index: 1000 or position: fixed. This value-based search works regardless of how the class names were generated.

Check the HTML for data attributes alongside obfuscated classes

Some build tools that obfuscate class names preserve readable data attributes in the HTML for testing purposes. Inspecting the element in DevTools may reveal a data-testid or data-component attribute that names the component, helping you locate the relevant rule block in the recovered CSS.

FAQ

Frequently asked questions

No. Class name obfuscation renames class names in both the CSS and HTML files during the build. The original human-readable names are not stored anywhere in the minified CSS output. The CSS file only contains the renamed classes. To recover original names, you need either the CSS source map (which maps positions to original names) or the build configuration that specifies the naming pattern. Whitespace recovery restores readability, not original naming, because names are not whitespace and were not simply removed but actively replaced.

Open DevTools and click on the element you are investigating. The Styles panel shows the applied class names, which match the obfuscated names in the recovered CSS. Copy the obfuscated class name from the Styles panel and search for it in the recovered CSS. You will find the full rule block, including all declarations. This workflow connects the element in the DOM to the rule in the recovered stylesheet without needing to know the original human-readable class name.

webpack with css-loader using the modules option is the most common source. It generates class names using a hash of the file path and original class name by default. Next.js, which uses webpack, applies the same transformation. Styled-components and Emotion (CSS-in-JS libraries) generate atomic or component-scoped class names that are not directly readable. Angular uses Emulated ViewEncapsulation which adds a scoping attribute to selectors. Tailwind with JIT mode preserves readable class names, so it does not produce obfuscated output.

Yes. Angular's ViewEncapsulation adds attributes like _ngcontent-xyz-c123 to selectors for scoping. These are attribute selectors in standard CSS syntax. The whitespace recovery treats them like any other selector token, placing the full selector on its own line in the recovered output. The attribute selectors are preserved exactly, and their scoping function is unaffected by the whitespace recovery.

Partially. If the design system uses CSS custom properties (var(--token-name)) and the build preserves those var() references, the recovered CSS will show them. If the build inlined the variable values by resolving var() calls to their computed values, the recovered CSS will show the resolved values without the token names. The former provides useful insight into the token structure; the latter does not.

No. CSS is always sent to the browser as text that the browser must parse and apply. Any user who opens DevTools can read the applied rules, and anyone can download the stylesheet file. Obfuscating class names makes CSS harder to read but does not prevent anyone from seeing what styles are applied. CSS should not be used to hide sensitive information. Access control and data security must be implemented server-side, not through CSS class name obfuscation.

The recovered CSS is syntactically correct and will work in a browser, but using it as a source file has limitations. If the build tool renamed class names, those names appear in the recovered CSS and must also be used in the HTML. The original HTML was likely also transformed to use the renamed classes. Using the recovered CSS without the corresponding transformed HTML will produce a mismatch where selectors no longer match their intended elements.

This is expected behaviour for hash-based naming. The hash changes when the source file or class name changes. If you are writing CSS overrides that need to survive deployments, avoid targeting obfuscated class names directly. Instead, use stable selectors: element type selectors, data-* attribute selectors, aria-* attribute selectors, or ID selectors. These are typically stable across deployments. The recovered CSS helps you read the full context and identify which stable selectors are available as hook points for overrides.

Vendor-prefixed properties are restored exactly as the minified file contained them and appear on their own indented lines like any other property. CSS Modules and CSS-in-JS builds typically run Autoprefixer as part of the pipeline, so the deobfuscated output may contain -webkit-, -moz-, and -ms- variants alongside the standard properties. The order is preserved from the minified input, with the unprefixed standard property usually last so modern browsers use it while older browsers fall back to the prefix they understand. After recovery, the prefixed properties become easy to audit because each one is on its own searchable line. If your project Browserslist target has tightened since the build was produced, you may find prefixes that no current browser requires; removing them at the source level shrinks the next build without affecting any user.

No. The recovered output adds whitespace at every structural boundary, which shifts every line and column position relative to the minified file. The original .css.map remains valid for the original minified file in DevTools, but pointing the same map at the recovered text will produce wrong mappings. The two artifacts answer different questions. The source map answers "what was the authored name and file?" by mapping minified positions to original positions. Whitespace recovery answers "what is the structure of the deployed CSS?" by inserting readable formatting. When both are available, prefer the source map for name tracing and use the recovered file for structural reading. They complement each other; they do not substitute for each other.