Free · Fast · Privacy-first

Format Minified HTML Online

Minified HTML is intentionally compressed for fast delivery to browsers, but it is unreadable for humans and useless for debugging, auditing, or learning from.

⚡

Unminifies single-line HTML instantly

🔒

Restores indentation and line breaks

✨

Handles deeply compressed output from build tools

⚡

Works entirely in your browser

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this HTML Formatter to your website

Drop the HTML Formatter 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/html/html-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/html/html-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Understanding Minified HTML and How to Reverse It

HTML minification removes all whitespace, comments, and unnecessary characters to reduce file size and improve page load speed. A minified HTML file can be twenty to forty percent smaller than its formatted equivalent, which translates directly to faster downloads, lower bandwidth costs, and quicker first paint times for visitors. Build tools such as webpack, Parcel, gulp-htmlmin, and various content delivery network edge platforms apply minification automatically during deployment. The result is a production asset that browsers parse efficiently but that humans cannot read without first reversing the compression. This is exactly the right trade-off for production HTML, where the audience is browsers rather than developers, but it leaves developers without a way to inspect their own deployed output.

Formatting minified HTML is often called unminifying, decompressing, or beautifying. The process is straightforward in concept: a parser reads the compressed token stream, reconstructs the element tree using the rules a browser would apply, and then re-emits each node with indentation based on its depth. FixTools handles all the standard HTML minification strategies that production tools apply, including whitespace stripping, comment removal, attribute quote removal, boolean attribute compression, and optional tag omission for elements such as li or td where HTML5 permits implicit closure. The formatted output restores the readable structure, though removed comments cannot be recovered because they were discarded during minification and the information is gone.

A key use case for unminifying HTML is debugging production issues. When a page behaves unexpectedly in a specific browser or under certain conditions, the fastest path to diagnosis is often to fetch the production HTML, format it, and compare it directly to the development source. Differences between the two reveal minification bugs where a minifier was too aggressive and removed something required, missing assets that the build pipeline failed to bundle, or server-side rendering issues where the rendered output differs from the source template. None of this is possible without first reversing the minification step.

Another common use case is reverse-engineering competitor pages or third-party templates. When you encounter an interesting layout, component, or pattern on another website, the page source is usually minified. Unminifying it lets you study the structure, understand the semantic choices, and learn from the implementation in a form your brain can process. This is a normal part of web development practice and the formatting tool makes it practical rather than tedious. The output gives you the same view of the markup that the original developers worked with before deployment.

HTML Living Standard (WHATWG)MDN: Authoring fast-loading HTML pages

How to use this tool

💡

Paste minified HTML into the input panel and click Format. The output restores all indentation and line breaks, making the structure readable again.

How It Works

Step-by-step guide to format minified html online:

1
Copy the minified HTML
Copy the minified HTML from your build output, production server response, browser source view, or wherever the compressed form lives. For production pages, fetching with curl or copying from the DevTools Network tab gives you the exact bytes the server sent rather than the post-render DOM.
2
Paste into FixTools
Paste the compressed HTML into the input panel on the HTML Formatter page. The parser accepts any length of input and any state of compression, including HTML that has been minified by multiple sequential passes through different tools.
3
Click Format
Click Format to run the parse and re-serialise step. The tool reconstructs the element tree from the compressed token stream and outputs readable indented HTML with proper line breaks between every block-level element.
4
Review and use
Review the formatted output for debugging, documentation, comparison against your development source, or any other purpose the readable form enables. The original minified input remains in place if you want to re-run the format with different indent settings.

Real-world examples

Common situations where this approach makes a real difference:

Debugging a production page rendering error

A React application's production build minifies HTML to a single line of one hundred eighty kilobytes. Formatting it in FixTools reveals a missing closing div that was silently auto-corrected by the browser parser in development but causes layout collapse in Safari in production where the parser handled the same input slightly differently. The structural fix takes minutes once the unminified output makes the problem visible.

Auditing a CMS-generated page

A WordPress page exported from a staging server produces minified HTML of forty-five kilobytes. Formatting it reveals twelve duplicate meta tags injected by conflicting SEO plugins, which are immediately removed by disabling one of the plugins before the page goes live. The duplicate tags were invisible in the compressed form because they ran together inline.

Reverse-engineering a competitor's page structure

A product team formats a competitor's minified homepage HTML, compressed from sixty-two kilobytes to thirty-eight kilobytes in production. The formatted output reveals their semantic structure, schema markup choices, and overall content organisation, informing the team's own redesign approach with concrete data about what the competitor prioritised structurally.

Verifying a Jamstack build output

After a Gatsby or Next.js static site build, the team formats the minified index.html to confirm that all Open Graph meta tags are present and correctly populated. The unminified output catches a build-time rendering issue where one meta tag was emitted with an empty content attribute before deployment, preventing the bug from reaching production where it would have broken social sharing previews.

When to use this guide

Use this when you receive minified HTML from a build pipeline, a production server, or a third-party tool and need to read, debug, or modify it.

Pro tips

Get better results with these expert suggestions:

Use curl to fetch and paste minified HTML directly

Run curl with the silent flag against your production URL to fetch the exact bytes the server sent, then paste the result into FixTools. This gives you the source HTML without any browser DOM manipulation layer altering it, which is essential when debugging server-side rendering issues or investigating differences between what the server emits and what the browser displays. The curl approach also bypasses any client-side JavaScript that modifies the DOM after load.

Format minified email HTML before testing client rendering

Email service providers often minify HTML aggressively before delivery to reduce send time and bandwidth. Before testing a campaign in Litmus or Email on Acid, format the minified version to verify the structure survived the minification step. Missing table cells, collapsed inline styles, and stripped boolean attributes are common casualties in email HTML minification, and many cross-client rendering bugs trace back to a minifier that was too aggressive on a template that needed preservation of certain whitespace patterns.

Use formatted output to write new unit tests

When reverse-engineering a legacy page with no source files or documentation, format the minified HTML and use the readable output as the basis for writing component tests. The formatted version gives you the exact structure needed to write accurate CSS selectors and DOM queries in your test code. This is particularly valuable when adopting a legacy codebase and trying to put a test harness around it before refactoring.

Look for injected third-party scripts after formatting

After formatting minified production HTML, scan the script tags in the output to identify what third-party services are loading on the page. Tag managers, analytics tools, ad networks, and customer support widgets often inject additional script tags at runtime or via content delivery network edge processing, and formatted HTML makes these additions visible and auditable. This is essential for performance audits, privacy reviews, and any investigation into why a page is slower than expected.

Fetch production HTML from DevTools

In Chrome DevTools, use the Network tab to find the main document request, then copy the response body. Paste it into FixTools to format the exact HTML your server is sending.

Compare formatted source to your dev file

After formatting the production HTML, compare it to your development source using a diff tool. Differences may reveal injected scripts, missing attributes, or CMS modifications.

Don't commit formatted production HTML as source

The formatted output is for reading and debugging, not for committing. Your version control source should be the pre-minification development file, not a round-tripped version of the minified output.

FAQ

Frequently asked questions

Yes. FixTools handles all standard HTML minification strategies including whitespace stripping, comment removal, optional quote removal on attribute values, boolean attribute compression, and tag omission for elements where HTML5 permits implicit closure. The formatter reconstructs the document tree from the token stream regardless of how aggressively the original was compressed, which means even output from the most aggressive production minifiers unminifies cleanly into readable form.

No. HTML comments are removed during minification and cannot be recovered from the minified output because the information is gone. Formatting will restore indentation and structure, but any comments in the original development source are permanently lost from the minified version. This is one reason production HTML should never be treated as a substitute for source code in version control. Keep the pre-minification source as the source of truth and use unminified production output only for inspection.

In Chrome or Firefox, press Ctrl+U on Windows or Cmd+U on macOS to open the page source view, which shows the raw HTML sent by the server before any client-side JavaScript modifies it. Alternatively, open DevTools, navigate to the Network tab, reload the page, click the main document request, and copy the response body. For automated or scripted fetching, curl with the silent flag against the production URL gives you exactly what the server emits.

There is no hard limit enforced by FixTools. The formatter runs entirely in your browser, so the practical limit is your device's available memory rather than any server-side constraint. Pages up to several megabytes of compressed HTML format without issues in all modern browsers on typical hardware. For exceptionally large pages, consider breaking the input into sections and formatting each separately, which is faster and produces more reviewable output.

Production HTML often differs from development source because content delivery networks, server-side rendering pipelines, deployment build tools, and edge computing layers all modify the HTML during processing. Minifiers strip whitespace and comments, server-side renderers inject data into placeholders, tag managers add script tags at the edge, and security headers may rewrite specific attributes. Formatting the production output and diffing it against your development source reveals all these modifications, which is essential for any serious production debugging session.

Yes. Inline SVG is valid HTML5 content and the formatter handles it correctly within the broader document structure. SVG elements are indented as part of the document tree using the same depth-based rules applied to HTML elements, so the SVG structure becomes readable alongside the surrounding HTML. Complex SVG paths and attribute values are preserved exactly without any reformatting of the path data, which is the correct behaviour because SVG path syntax has its own structural rules that HTML formatters should not touch.

No. Formatting only adds whitespace between elements, and the browser parses formatted and minified versions of the same HTML identically. The document structure, attribute values, content, and behaviour are all preserved exactly. The only change is the addition of spaces and line breaks between elements, which the layout engine ignores during rendering. You can confidently format production HTML for inspection without worrying that you are introducing functional changes that would affect how the page behaves.

Minified HTML is typically twenty to forty percent smaller than formatted HTML, depending on the original indentation depth and the number of comments in the source. A formatted page of sixty kilobytes might minify to thirty-eight to forty-eight kilobytes. For most pages this difference is small compared to the size of images, fonts, and scripts, but it adds up at scale for high-traffic sites where bandwidth costs and visitor connection speeds make every kilobyte meaningful. Minification is the right production default for any non-trivial site.

Yes. After formatting minified HTML for inspection, you can run the formatted output back through a minifier to compare the round-trip result against the original. If the two minified versions match, the formatter preserved all content correctly. If they differ, either the original had structural quirks that the formatter normalised or the minifier is non-deterministic in some way. This round-trip check is a useful sanity test when adopting a new formatter into a workflow.

Yes, almost always. A bug report that includes formatted production HTML is significantly easier to triage than one that includes only the minified form. The triaging engineer can immediately see the structural element causing the problem rather than spending time on the formatting step themselves. Treating formatting as a courtesy step when filing bug reports against frameworks or libraries makes the report more likely to be taken seriously and resolved quickly. Reverse-formatting minified HTML is useful for inspecting third-party widget code or debugging unexpected page output from CMS systems.

Several reasons: debugging issues that only appear in production builds, reviewing what the minifier actually produced (sometimes it makes choices you would not), inspecting third-party widget code embedded in your site, or modifying minified output for testing without rebuilding. Many CDN-served libraries ship as minified HTML/JS, and understanding their structure requires reverse-formatting first. Browser DevTools include a built-in Pretty Print feature that does this for in-page debugging, but a standalone formatter is more powerful for processing larger files or batches.

Look for these indicators of minification: very long single lines (often thousands of characters), no consistent indentation between tags, attributes packed without spaces, and minimal whitespace between elements. Hand-written HTML usually has line breaks between major elements, consistent indentation, and readable spacing around attributes. If you see html minified with one-letter variable names or aggressive character compression, you are looking at production-built output. A formatter reverses this back to readable form so you can study the structure for learning or debugging purposes.