Free · Fast · Privacy-first

Format HTML Tags Online

Correct tag handling is the foundation of well-formed HTML, and a formatter that does not understand the difference between block, inline, and void elements will produce output that looks formatted but actually breaks rendering in subtle ways.

⚡

Correctly handles block, inline, and void elements

🔒

Places each block tag on its own line

✨

Preserves inline elements within text flow

⚡

Free with no sign-up required

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.

How HTML Tag Types Determine Formatting Rules

HTML tags fall into three categories that determine how a formatter should treat them, and understanding these categories is essential for evaluating any formatting tool. Block-level elements such as div, section, article, p, h1 through h6, ul, ol, and table each occupy their own line and indent their children one level deeper. Inline elements such as span, a, strong, em, code, small, and time stay within the text flow of their parent and do not force new lines because adding line breaks around them would introduce whitespace that browsers may render as small visible gaps. Void elements such as img, br, hr, input, link, and meta have no closing tag and no children, and they are placed on their own lines at the appropriate depth without any closing tag being added. A formatter that does not distinguish between these categories produces incorrect output for real-world HTML.

FixTools applies the HTML5 element content model to determine how each tag is formatted in the output. The formatter knows which elements are block-level and places them on their own lines with correct indentation. Inline elements are kept in the same text run as their siblings to preserve reading flow and avoid introducing whitespace gaps. Void elements are placed on their own lines at the correct depth without a closing tag, matching the HTML5 specification's treatment of self-closing elements. This means the formatted output matches how browsers actually interpret the HTML, making it easier to reason about rendering behaviour from the source code alone.

Custom elements present a special case in HTML5. Any element name that is not recognised as a standard HTML element is treated as a block-level element by default, which is consistent with how browsers handle unknown elements per the HTML5 unknown element handling specification. Web components, framework-specific elements such as router-outlet from Angular or ion-button from Ionic, and any project-defined custom element with a hyphenated name are therefore formatted as block elements with their own lines and child indentation. This works correctly for the vast majority of custom element usage in real-world projects because custom elements are almost always intended to behave as blocks.

A subtle but important point is that the formatter respects the HTML5 content model rather than enforcing rules from earlier HTML versions or from XHTML. This means void elements appear without trailing slashes by default if your input did not include them, and they appear with trailing slashes if your input used the self-closing XHTML style. The formatter preserves your choice rather than imposing one. This matters for projects that prefer one style for consistency reasons and for build pipelines that may transform one style into the other before deployment.

MDN: HTML elements reference HTML Living Standard: Void elements

How to use this tool

💡

Paste HTML with any tag structure and click Format. The output correctly indents block elements, keeps inline elements in context, and places void elements properly.

How It Works

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

1
Paste your HTML
Paste any HTML with any tag structure into the input panel of the HTML Formatter. The tool accepts fragments containing only inline elements, complete documents with full doctype declarations, or anything in between, and the parser handles all of these with the same content model rules.
2
Click Format
Click Format to run the parse and re-serialise step. The tool applies correct formatting rules for block, inline, and void elements based on the HTML5 specification, producing output that matches how browsers actually interpret the same input.
3
Review tag structure
Scan the formatted output to verify closing tags are in the expected places, nesting depth matches your intent, and void elements appear without closing tags. The indented structure makes structural issues immediately visible in a way that compressed HTML never can.
4
Copy the formatted HTML
Copy the clean, tag-correct HTML with the clipboard button and use it in your project, pull request, documentation, or test code. The original input remains in place in case you want to re-run with different indentation settings.

Real-world examples

Common situations where this approach makes a real difference:

Debugging a CSS selector that stops matching after a CMS update

A navigation component stops responding to its CSS selector after a CMS update. Formatting the new HTML output reveals that the nav element is now wrapped in an additional div injected by the CMS, shifting the selector path by one level and breaking the rule. The fix is a one-character selector adjustment, but identifying the cause required formatting.

Reviewing a vendor-supplied HTML template

A vendor delivers a twenty-eight kilobyte HTML email template with no indentation whatsoever. Formatting reveals three unclosed table rows and two img tags with stray closing tags, all of which are fixed before the template is sent to any subscribers. The structural issues were invisible in the unformatted form and would have caused rendering bugs in older email clients.

Writing Cypress end-to-end tests for a new feature

A developer formats the feature's HTML output before writing tests so the tag hierarchy is unambiguous. The clear structure reduces test authoring time compared to inspecting compressed output in DevTools, and the resulting tests are less brittle because the selectors are based on the actual structural relationships rather than guesses about nesting.

Auditing ARIA attributes in a form component

An accessibility reviewer formats a twelve kilobyte form HTML before review. The indented structure immediately surfaces an aria-describedby pointing to a non-existent element ID, which would have been missed entirely in the minified version because the ID values were not visible alongside their referencing attributes.

When to use this guide

Use this when you want to verify and clean up tag structure, ensure all open tags have matching closes, void elements are handled correctly, and nesting is visually clear.

Pro tips

Get better results with these expert suggestions:

Use formatted output to audit ARIA landmark roles

After formatting, the indented structure makes it straightforward to verify that ARIA landmark roles such as role main, role navigation, and role banner are on the correct elements and are not nested inside each other incorrectly. This kind of structural audit is much harder on compressed HTML because the landmark relationships are not visible without trace-counting tag pairs. Formatted output turns an hour-long landmark audit into a fifteen-minute scan that catches the same issues with less fatigue.

Format to catch implicit closing tag assumptions

Some HTML elements such as li, dt, dd, and td have optional closing tags that browsers infer automatically per the HTML5 parsing rules. When formatting, FixTools adds the missing closes where the specification allows implicit closure, which makes your structural intent explicit. Review these additions to confirm they match what you actually wanted, because in rare cases the parser's inferred closure point may not match your mental model of where the element should have ended.

Use tag-level formatting to debug CSS selector issues

When a CSS selector is not matching as expected, format the HTML and trace the element path visually from root to target. Indentation makes the exact parent-child and sibling relationships visible, which is often faster than using browser DevTools for simple selector debugging. This is especially useful when the selector relies on combinators such as direct child or general sibling that depend on precise structural relationships.

Format custom element HTML before writing automated tests

When writing Playwright or Cypress end-to-end tests for pages that use custom elements or web components, format the HTML first so the tag hierarchy is unambiguous. The formatted structure gives you the exact tag path you need to write accurate CSS selectors and ARIA queries in your test code, which prevents the frustrating situation where a test fails because the selector matched the wrong element due to structural confusion in the source HTML.

Check void element usage after formatting

After formatting, scan for any img, input, or hr tags to confirm they have no closing tags. Stray </img> or </br> tags indicate non-standard markup that may cause parsing inconsistencies.

Use the output to verify nesting visually

Formatted output makes it immediately obvious when a closing tag is in the wrong place. If the indentation shifts unexpectedly, a mismatched tag is almost always the cause.

Inline elements within block context is expected

Seeing a span or a inside a p without its own indented line is correct behaviour, not a bug. The formatter keeps inline elements within their text flow intentionally.

FAQ

Frequently asked questions

Void elements are placed on their own lines at the correct indentation depth but are never given closing tags. The formatter follows the HTML5 specification list of void elements: img, br, hr, input, link, meta, area, base, col, embed, param, source, track, and wbr are all treated as self-contained with no children and no closing tags. Whether the input used bare void tags such as br or self-closing XHTML style such as br with trailing slash, the formatter preserves whichever style you used.

The formatter uses an error-tolerant HTML parser that follows the same implicit closing rules browsers use per the HTML5 parsing specification. Unclosed tags are closed at the most logical point based on the spec, and the output will include the auto-closed tags. This may reveal structural issues in your original HTML that were being silently corrected by the browser, which is often valuable information when debugging unexpected rendering behaviour. Review the closures to confirm they match your intent.

No. Inline elements such as span, a, strong, em, code, and small are kept on the same line as their parent's text content. This is intentional rather than a limitation: adding line breaks around inline elements introduces whitespace that can cause small visible rendering gaps in some browsers, sometimes called the inline-block whitespace problem. The formatter correctly preserves the inline context by keeping these elements in the text flow, which produces output that renders identically to your original input.

Yes, for elements that require closing tags in HTML5. If a div, section, p, or other non-void element is missing its closing tag, the parser infers the closure point based on the specification and the formatter includes the closing tag in the output at the correct position. This makes your structural intent explicit and reveals any structural ambiguity in the original. For elements that have optional closing tags such as li or td, the formatter adds the closure where the spec permits implicit closure.

Custom elements with hyphenated names such as my-component, app-product-card, or ion-button are formatted as block-level elements by default. They appear on their own lines with correct depth indentation and any child elements are indented one level deeper than the custom element. This matches the browser's default block rendering for unknown elements under HTML5 rules and works correctly for the vast majority of custom element usage in real-world projects.

Yes. All HTML5 semantic elements including header, footer, main, section, article, aside, nav, figure, figcaption, time, mark, details, summary, and dialog are fully supported and formatted as block-level elements with correct indentation. The formatter's element content model is kept current with the HTML Living Standard, so any standard semantic element is recognised and handled correctly without requiring configuration.

Yes. The formatter accepts both HTML5 style void tags written as br and XHTML-style self-closing tags written as br with a trailing slash. Both are treated as void elements in the output. The formatter does not add or remove the trailing slash. It preserves whichever style you used in the input, which means projects that prefer one style for consistency reasons can rely on the formatter to maintain that style across all files.

The formatter applies formatting rules based on the HTML5 content model, not on whether your usage is semantically correct. An inline element placed where a block element is expected may produce unexpected indentation because the formatter is following the content model strictly. Use the HTML Validator after formatting to identify incorrect element nesting and other semantic issues that are independent of formatting. The validator and formatter complement each other rather than overlapping in function.

Yes. Custom elements from any framework or library are treated as block-level elements by default because their names contain hyphens and they are not part of the standard HTML element set. This works correctly for Angular elements such as router-outlet, Ionic elements such as ion-button, Lit and Stencil web components, and any project-defined custom element. The formatter does not need a registry of known custom elements because the general rule for unknown hyphenated tags handles all cases correctly.

Indirectly yes. The formatter does not specifically check for missing alt attributes, but the formatted output makes every img tag visible on its own line with all of its attributes, which makes scanning for missing alt attributes a quick visual exercise. For automated detection, use an HTML validator or an accessibility linter after formatting. The two tools together give you both readable output and automated checking for the most common accessibility omissions. Tag-level formatting is useful when copy-pasting small snippets from documentation or Stack Overflow.

Tag-level formatting focuses on individual elements and their attributes rather than restructuring an entire document. It is useful when copy-pasting snippets from documentation, fixing the formatting of a single component, or normalizing inline styles within a larger template. Most online formatters offer both modes: full document formatting (with doctype handling, proper indentation, semantic structure) and snippet formatting (just the pasted tags, formatted in isolation). Use snippet mode for code review comments and documentation examples, full mode for entire page audits and pre-deploy quality checks.