HTML Formatter

An HTML formatter takes a document or fragment and re-indents it so the tree structure is visible: each element starts on its own line, attributes line up, and the nesting depth tells you which container owns which content. It does not change which elements exist, what attributes they carry, or how the browser will render them — it only changes how the markup looks when a human reads it.

Why HTML in the wild rarely arrives indented

Production HTML is usually compiled from templates, generated by a CMS, or copied from rendered output. Whitespace between elements is mostly ignored by the renderer but takes bytes, so build pipelines routinely strip it. By the time a maintainer needs to read the markup — to debug a layout, audit a snippet for accessibility, or extract a component — the structure has to be reconstructed visually. A formatter does that mechanically.

What the formatter changes, what it must keep identical

Formatting touches whitespace between elements, indentation depth, and attribute alignment. It must not change the element tree, attribute names, attribute values, text content, comments, or anything inside <pre>, <textarea>, <script>, and <style>, where whitespace is semantically significant.

• Block-level elements each start on their own line so the document outline reads like an outline.
• Children indent one level deeper than their parent, with consistent space-or-tab width.
• Inline elements stay inline unless they make a single line unreadable, so prose does not get torn into one-word lines.
• Whitespace inside <pre>, <textarea>, <script>, and <style> is preserved verbatim — those areas are off-limits.
• Attribute order, attribute values, and HTML entities are kept exactly as-is — encoding decisions belong to authors, not to a formatter.

Rule of thumb: formatting must leave the rendered page byte-for-byte identical. If indenting your HTML changes how the page looks in a browser, something other than formatting is going on.

How to use this tool

1. Prepare representative HTML fragments and copied markup that need clean review-friendly structure in HTML Formatter instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate formatted HTML that is easier to review before publishing or embedding, and review nesting depth, attributes, entity text, inline scripts, inline styles, and whether the source is really HTML rather than escaped text before deciding the result is ready.
3. Only copy or download the result after it fits template review, CMS cleanup, snippet sharing, and docs examples and no longer conflicts with this constraint: Formatted HTML can still be semantically wrong or unsafe, so review the markup in its real rendering context before publishing.

HTML Formatter example

This HTML Formatter example uses representative HTML fragments and copied markup that need clean review-friendly structure and shows the resulting formatted HTML that is easier to review before publishing or embedding, so you can confirm nesting depth, attributes, entity text, inline scripts, inline styles, and whether the source is really HTML rather than escaped text before applying the same settings to real input.

Sample input

<main><h1>Tools</h1><p>Fast utilities.</p></main>

Expected output

<main>
  <h1>Tools</h1>
  <p>Fast utilities.</p>
</main>

A compacted snippet, restored to a reviewable tree

<!-- before — typical of CMS or build output -->
<article class="card"><header><h2>Title</h2><p class="meta">Updated today</p></header><section class="body"><p>Lead paragraph that summarises the article.</p><ul><li>First point</li><li>Second point</li></ul></section></article>

<!-- after — easy to scan and diff -->
<article class="card">
  <header>
    <h2>Title</h2>
    <p class="meta">Updated today</p>
  </header>
  <section class="body">
    <p>Lead paragraph that summarises the article.</p>
    <ul>
      <li>First point</li>
      <li>Second point</li>
    </ul>
  </section>
</article>

Where reformatting HTML pays for itself immediately

HTML is read by far more people than write it. The list below collects the situations where having a clean, indented version of the markup is the difference between a five-minute task and an hour of squinting.

• Reviewing a CMS-generated page when an editor reports a layout problem and you only have the rendered HTML.
• Extracting a component from a static-site build, where everything came out of the pipeline already collapsed.
• Comparing two snapshots of the same page across deploys to see what really changed in the DOM.
• Auditing accessibility — landmark structure, heading order, and ARIA attributes are far easier to verify on an indented tree.
• Teaching or documenting HTML — readers cannot internalise nesting from a single-line dump, but they can from a tree.

Edge cases worth understanding before you format

Most HTML formatters are conservative on purpose because HTML hides a few traps that other formats do not have. Walking through them once makes it much easier to tell whether a surprising diff is a bug or a deliberate decision.

• Whitespace inside <pre>, <textarea>, <code> with white-space: pre, and inline blocks like <span> can change layout — these must not be touched.
• Self-closing markers like <br/> vs <br>: HTML5 treats them the same, but XHTML and some template engines do not. A formatter should keep whatever the source used.
• Conditional comments and templating placeholders (<!--[if IE]-->, {{ }}, {% %}, <?= ?>): these are not real HTML but pass through the formatter unchanged.
• Inline scripts and styles: their contents are JS or CSS, not HTML. Do not let an HTML formatter recursively reformat them; use the dedicated formatters for those languages.
• Whitespace-sensitive layouts: stacking `<span>` chips inline often relies on the space between tags. Forcing each into its own line can collapse the row in the rendered page.

HTML formatter vs related tools

Practical Notes

• Review nesting depth, attributes, entity text, inline scripts, inline styles, and whether the source is really HTML rather than escaped text before you reuse the formatted HTML that is easier to review before publishing or embedding.
• Formatted HTML can still be semantically wrong or unsafe, so review the markup in its real rendering context before publishing.
• Keep the original HTML fragments and copied markup that need clean review-friendly structure available when the result affects production work or customer-visible content.

HTML Formatter reference

HTML Formatter reference content should stay anchored to HTML fragments and copied markup that need clean review-friendly structure, the generated formatted HTML that is easier to review before publishing or embedding, and the checks needed before template review, CMS cleanup, snippet sharing, and docs examples.

• Input focus: HTML fragments and copied markup that need clean review-friendly structure.
• Output focus: formatted HTML that is easier to review before publishing or embedding.
• Review focus: nesting depth, attributes, entity text, inline scripts, inline styles, and whether the source is really HTML rather than escaped text.

References

• WHATWG HTML Living Standard
• MDN: HTML