Free · Fast · Privacy-first

CSS One-Liner Expander

CSS from CDN-hosted libraries, inline style attributes, and style tags in HTML templates often arrives as a single dense line.

⚡

Identifies selector and declaration boundaries in dense one-liner CSS

🔒

Expands inline style attribute content as well as full stylesheets

✨

Handles style tags extracted from HTML pages

⚡

Instant browser-based processing, nothing uploaded

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.

Identifying Selector Boundaries in a Minified CSS Blob

The challenge with a CSS one-liner is that there are no visual breaks to tell you where one rule ends and the next begins. A block like .a{color:red}.b{font-size:14px}.c{margin:0} has obvious breaks because each rule is short. A real-world minified stylesheet has rules that run for hundreds of characters before the closing brace, and identifying where a selector ends and its declaration block begins requires counting braces. The expander does this automatically by parsing the token stream and identifying every opening brace, closing brace, and semicolon as structural markers.

Inline style attributes are a slightly different case. A style attribute value like color:#333;font-size:14px;line-height:1.5;padding:8px 12px is a list of CSS declarations without any selector or braces. The expander handles this as a bare declaration block: it places each property-value pair on its own line without adding a selector. This is the correct interpretation of an inline style value, since inline styles always apply to the specific element they are on.

Style tags embedded in HTML documents are the most complex case. A style tag may contain multiple @media rules, @keyframes blocks, and dozens of regular rule sets, all concatenated into a dense block. When you extract the content of a style tag (just the CSS text between the opening and closing style tags, not including the HTML tags) and paste it into the expander, it handles the full range of at-rules, nested blocks, and regular rule sets. The output mirrors the structure a developer would have written with full formatting and indentation.

Once a one-liner is expanded, the question of line length becomes immediate. A single rule that started as part of a 50,000-character one-liner may expand into a declaration that is itself 200 characters long, especially if it contains a complex linear-gradient with many colour stops, a multi-layer box-shadow, or a comma-separated selector group that cssnano merged from several source rules. The expander keeps each declaration on one line because hard-wrapping inside a CSS value introduces whitespace the parser does not expect and can break calc() and var() chains in subtle ways. For lines that genuinely exceed your team comfort range of 100 to 120 characters, the productive response is structural: split merged selectors into separate rule blocks, extract long values into named custom properties at :root, and move multi-stop gradients onto their own variable definitions. Wrapping mid-value rarely improves readability and routinely causes parsing surprises.

MDN Web Docs: style attribute MDN Web Docs: The style element

How to use this tool

💡

Paste any CSS one-liner (a complete stylesheet on a single line, an inline style value, or CSS from a style tag) into the input. The expander identifies every rule boundary and outputs the code as a readable multi-line formatted stylesheet.

How It Works

Step-by-step guide to css one-liner expander:

1
Find the CSS one-liner
Locate the compressed CSS text. For CDN links, open the URL directly in a browser tab to see the raw one-liner. For inline styles, copy the attribute value. For style tags, copy the content between the style element opening and closing tags.
2
Select and copy the entire line
Use Ctrl+A to select all content in the browser tab or file view. Copy with Ctrl+C. Verify the entire one-liner is selected, as partial copies of minified CSS produce incomplete formatted output.
3
Paste into the CSS One-Liner Expander
Open FixTools CSS Unminifier and paste into the input panel. The tool accepts any length of one-liner input and processes it the same way regardless of whether the input is a single declaration list or an entire production stylesheet bundle.
4
Review the expanded output structure
Scroll through the expanded output to understand the overall structure. Note the number of rule blocks, the breakpoints used in @media rules, and any at-rules like @keyframes. This structural overview helps you navigate the file when searching for specific rules.

Real-world examples

Common situations where this approach makes a real difference:

Reading a CDN-hosted icon library stylesheet

An icon library hosted on a CDN provides its CSS as a single minified one-liner containing hundreds of rules for each icon class. A developer needs to understand which icon class names are available and what properties they set. They open the CDN URL, copy the response, expand the one-liner with FixTools, and search the formatted output for icon-related class names. The expanded output makes the pattern immediately clear and helps them find the correct class names for the icons they need.

Debugging an inline style override that is not working

A React component sets an inline style object that gets serialised as a style attribute with concatenated declarations. The developer wants to understand all the properties being applied before debugging why one of them is not rendering correctly. They copy the style attribute value, paste it into the expander as a bare declaration list, and get a readable view of every property and value. This reveals that two conflicting properties are being set simultaneously, explaining the unexpected rendering.

Auditing a CMS-injected style block

A content management system injects a style block into every page containing theme CSS. The style tag content is minified into a one-liner. An engineer needs to understand what the CMS is injecting before deciding whether to override it. They copy the style tag content, expand it, and find that the CMS is injecting font-face declarations and body typography rules that are already being handled by the site's own stylesheet, suggesting an opportunity to remove the CMS injection.

Understanding a design tool export

A design tool like Figma or Framer exports component CSS as a compact block. The export format uses minimal whitespace to keep the generated code small. A developer copies the exported CSS into the expander to read the full property set before incorporating it into their own stylesheet. The expanded output reveals that the design tool used fixed pixel values for spacing, which they need to convert to rem units before integrating.

Pro tips

Get better results with these expert suggestions:

Use expand-then-diff to compare CDN versions

When a CDN-hosted library releases a new version, expand both the old and new minified one-liners with the CSS expander, save each as a separate .css file, and compare them with a diff tool. The diff on expanded files shows exactly which rules changed, which properties were added, and which values were modified, rather than showing a character-level diff of two dense one-liners.

Expand and split by @media to understand breakpoints

Production CSS one-liners often contain multiple @media rules concatenated together. After expanding, search for @media to find each breakpoint block. This gives you a clear picture of how many breakpoints the stylesheet uses and which properties change at each one, which is useful for mobile debugging or responsive redesign work.

Identify framework resets in concatenated bundles

Many production CSS one-liners are concatenated bundles containing a CSS reset or normalize.css followed by component styles. After expanding, the reset typically appears first as a long series of element selectors with default-cancelling properties. Identifying where the reset ends and component styles begin helps you understand which styles you can safely override.

Look for duplicate selector blocks after expanding

Concatenated CSS bundles sometimes contain the same selector multiple times, once from a base stylesheet and again from a component stylesheet. After expanding, search for a selector name and count how many times it appears. Multiple occurrences suggest that the bundle concatenation may have unintentionally duplicated rules, which adds file size without adding styles.

Copy just the attribute value for inline styles

When expanding an inline style, copy only the value inside the quotes, not the entire attribute. For style="color:red;padding:8px", copy color:red;padding:8px. Including the attribute name and equals sign will cause a parse error since those are not valid CSS.

Strip script wrapper before pasting CSS from JavaScript

CSS sometimes appears as a string assigned to a JavaScript variable like const styles = ".a{color:red}". Copy only the content inside the quotes, not the JavaScript assignment. The expander expects CSS syntax as input, not JavaScript.

Scroll to the end of the one-liner before copying to ensure nothing is truncated

When viewing a CSS one-liner in a browser tab or terminal, the display may visually truncate long lines. Before copying, use Ctrl+A to select the entire content, which ensures the full line is captured even if it extends beyond the visible area.

FAQ

Frequently asked questions

A CSS one-liner is a stylesheet or declaration block where all content appears on a single line with no newlines at all. Normal minified CSS may have a few newlines for very long files, but one-liners have none. They are common in CDN-hosted libraries where every byte matters, in CSS strings embedded in JavaScript bundles, and in inline style attributes. The expander handles one-liners and multi-line minified CSS equally, since the parser works on the token stream rather than line breaks.

Yes. You can paste any syntactically complete portion of CSS: one rule block, several rule blocks, a single @media query, or an entire stylesheet. The expander does not require a complete stylesheet. However, if you paste a partial rule (for example, stopping mid-declaration before the semicolon), the output for that incomplete portion may be malformed. Ensure any fragment you paste includes complete rule blocks with opening and closing braces.

Vendor-prefixed properties in inline styles such as -webkit-transform:translateX(10px) are standard CSS declaration tokens. The expander places each prefixed property on its own line, identical to how it handles unprefixed properties. Multiple declarations in a style attribute, including any vendor-prefixed ones, are each placed on their own line in the expanded output.

Unexpected output near a section usually indicates a syntax error in the input. CSS one-liners can contain errors that are not visible until the structure is expanded. A missing semicolon at the end of a declaration, an unclosed brace, or an invalid property value will cause the parser to enter error-recovery mode and skip ahead to the next known structural point. Validating the expanded output with the FixTools CSS Validator identifies the specific errors and their locations.

Yes. :root blocks containing CSS custom property declarations are rule blocks like any other. The expander places the :root selector on its own line, the opening brace on the same line, each --variable: value declaration on an indented line, and the closing brace on its own line. This makes even long lists of design tokens easy to read and search in the expanded output.

The expander processes CSS in your browser's JavaScript engine, which handles strings of millions of characters. Modern production CSS one-liners are typically between 20,000 and 500,000 characters. Files in this range expand in under a second. Even very large bundled stylesheets approaching 2 to 3 megabytes of minified content will expand within a few seconds. The practical limit is determined by your device's available memory rather than any fixed tool constraint.

Tailwind CSS generates utility class CSS that, when minified, produces a very long one-liner with thousands of single-property rule blocks. The expander handles this correctly, placing each utility class rule on its own set of lines. The output will be very long (thousands of lines) because Tailwind generates one rule per utility class. Use your editor's search function to locate the specific utility class you are investigating rather than scrolling through the entire expanded output. Searching for the exact class name plus a colon, like .text-red-500 {, lands on the rule definition immediately.

Yes. If you see a link tag in the HTML source of a page, for example link href="https://cdn.example.com/style.min.css", copy that URL and open it directly in a new browser tab. The browser will display the raw CSS content as a text response. Select all with Ctrl+A, copy with Ctrl+C, and paste into FixTools. This avoids DevTools navigation entirely and is often the fastest approach when you can see the stylesheet URL in the page source.

Prettier is a full opinionated formatter that enforces print width, sorts certain declarations into canonical order, and reflows long lines according to a configured strategy. The expander does the narrower job of breaking a dense token stream into one-declaration-per-line readable structure. For a one-off inspection of an unknown CDN file or an injected one-liner from a third party, the expander wins on speed because there is no install, no config file, and no Node version dependency. For long-term ownership of a stylesheet you maintain, Prettier integrated with your editor and pre-commit hooks gives stronger guarantees because every save re-applies the convention. The honest pattern is to use the expander to make the content readable, then paste into a Prettier-managed project if you intend to keep working in it past the initial read.

The original source map remains valid for the original one-liner content as long as DevTools can fetch the .css.map file referenced at the bottom of the file. Once you expand the one-liner, every line and column position shifts, and the original map no longer aligns with the expanded copy. If the source map is reachable and you primarily need to debug in the browser, work from the one-liner with the map attached and let DevTools show the authored source in the Sources panel. If the map is stripped, returns 404, or was never emitted, the expanded output is the right artifact. Mixing the two (using the original map against the expanded text) produces misleading line references that will waste debugging time.