HTML Formatter

Use formatting to expose the DOM shape

Dense HTML hides relationships that are obvious in a browser’s parsed tree. A closing </section> can sit hundreds of characters from its opening tag; a long component tag can bury the attribute that changed; embedded style and script text can turn the whole fragment into a wall. This online HTML formatter reorganizes that source into an indented view while keeping an input pane beside the generated output.

Formatting happens immediately. Select two spaces, four spaces, or tabs; decide whether comments remain; optionally place attributes on separate lines. Recognized block elements are broken across lines, while inline elements generally stay in the surrounding text flow. Content inside <style> and <script> receives a lightweight formatting pass of its own. The result can be copied or downloaded as formatted.html.

The page is a beautifier, not an HTML conformance checker or browser parser. Its tokenizer and formatters use practical string rules. That makes it useful for ordinary snippets, but malformed markup, raw-text edge cases, template syntax, and complicated JavaScript or CSS require review.

See the hierarchy emerge

Start with a compact card:

<article class="card" data-state="new"><h2>Release <span>1.4</span></h2><!-- owner note --><p>Read the <a href="/notes">notes</a>.</p><style>.card{padding:1rem;color:#222;}</style></article>

With two spaces, comments kept, and attribute wrapping enabled, the formatter separates the block structure, retains inline phrasing, and expands the style declarations. The exact output follows the formatter’s block-tag list: article, headings, paragraphs, and style are treated as blocks; span and a stay inline.

This distinction is central to readable HTML. Breaking every tag onto a new line can inject confusing whitespace into prose and make a sentence harder to review. Keeping every tag inline has the opposite problem for page structure. The formatter uses a fixed set of common block names including document sections, headings, lists, tables, forms, landmarks, pre, blockquote, script, and style.

Choose a layout policy

Two spaces, four spaces, or tabs

The Indent selector controls each nesting step in generated output. Two spaces is the default and keeps deeply nested markup narrower. Four spaces creates stronger visual separation. Tabs defer display width to the editor. This is a style choice; HTML parsing does not derive parentage from indentation.

Keep or remove comments

Keep Comments is enabled initially. Recognized <!-- ... --> blocks are retained and placed on an indented line. Disable it to omit comments from output. The input is never altered. Remember that comments can hold build directives, template markers, tests, or documentation even though they are not rendered as page text.

Wrap attributes

When Wrap Attributes is active and a tag contains multiple recognized pieces, attributes are placed on separate lines beneath the tag name, with the closing bracket aligned to the tag level. This is especially useful for elements carrying ARIA properties, data attributes, and utility classes:

<button
  type="button"
  aria-expanded="false"
  data-panel="filters"
>

The attribute tokenizer handles common quoted, single-quoted, and unquoted values. Framework expressions containing unusual delimiters may not be segmented as their compiler expects.

Embedded CSS and JavaScript: useful, deliberately simple

Style text is whitespace-collapsed, then braces, semicolons, and colons drive indentation and spacing. This can make a basic rule set readable:

.panel {
  display: grid;
  gap: 1rem;
}

It is not a CSS parser. Colons and semicolons inside strings, data URLs, custom constructs, or comments can confuse the pass. Modern nested syntax and at-rule nuances are not interpreted semantically.

Script text is formatted around braces and semicolons. Single, double, and template-quoted strings are recognized sufficiently to avoid treating braces inside a currently open string as structure. Semicolons inside an unmatched parenthesis on the current line remain inline. Even so, regular expression literals, comments, template interpolation, automatic semicolon insertion, and many grammar details are beyond this routine. Use a JavaScript formatter for production code after using the HTML view to understand placement.

A careful cleanup sequence

1. Preserve the original file, especially if it contains server templates or framework directives.
2. Paste the relevant document or fragment into Input HTML.
3. Select the indentation convention used by the repository.
4. Keep comments on during the first comparison so nothing informational disappears unnoticed.
5. Enable attribute wrapping only when long tags benefit from vertical scanning.
6. Compare inline prose and whitespace around a, span, strong, and similar elements.
7. Inspect every <script> and <style> block for syntax-sensitive changes.
8. Copy the output into an editor or download formatted.html.
9. Run the project’s HTML, template, CSS, and JavaScript checks before committing.

The Clear action empties input and output. Copy and Download are enabled whenever output exists; unlike the XML formatter, this component has no error state that disables export. That absence is not evidence of valid markup.

How text whitespace is treated

Ordinary text tokens have runs of whitespace collapsed to one space. Leading or trailing text spacing can be trimmed when neighboring tokens are recognized block elements or comments. This often cleans source indentation, but HTML whitespace behavior depends on element context and CSS. In <pre>, <textarea>, scripts, styles, and white-space-sensitive layouts, textual normalization can change what users or code observe.

Although pre appears in the block-tag list, its text is still handled by the general text-token whitespace rule. Do not use this formatter when exact preformatted text must remain byte-for-byte intact. The same caution applies to inline spacing where two text nodes and an inline element form a sentence.

HTML parsing realities the formatter does not model

Browsers follow the WHATWG HTML parsing algorithm, including error recovery, implied elements, void elements, raw-text states, and context-dependent insertion modes. This formatter instead finds a > to end a tag and tracks nesting with straightforward levels. It recognizes common void elements such as img, br, hr, input, link, meta, source, col, embed, param, track, area, base, and key as self-closing-like tokens.

It does not validate nesting rules, require document metadata, test ARIA, or identify obsolete elements. A typo may simply be indented. A browser might repair malformed table markup in a way the output does not reflect. Custom elements are tokenized, but because they are not in the fixed block set, they follow inline handling unless surrounding structure creates breaks.

Template languages introduce another layer. JSX, Astro expressions, Vue directives, Angular syntax, ERB, Liquid, and Handlebars are not explicitly parsed. Characters such as > inside an expression or unusual attribute constructs may terminate a token early. Prefer each framework’s official formatter for complete source files.

Where a free online HTML beautifier earns its place

It is excellent for making a copied email fragment legible, examining a CMS field, organizing a small static page, reviewing generated markup, or presenting an isolated reproduction in an issue. The side-by-side arrangement helps you spot what normalization changed without first installing tooling.

For a repository, formatters such as the one already configured by the project should remain authoritative. They understand team settings and can run consistently across files and continuous integration. This page is an inspection and one-off cleanup utility, especially when the source is short enough to review manually.

Review hazards before using the output

• Whitespace runs in text are collapsed.
• Comment removal can discard nonvisual directives.
• Embedded CSS and JavaScript formatting is grammar-light.
• Attribute wrapping is based on a regular-expression tokenizer.
• There is no mismatched-tag report.
• HTML semantics and accessibility are not checked.
• Preformatted content does not receive special preservation.
• Template expressions may not survive as intended.

Formatter FAQ

Does this validate HTML5?

No. It formats recognized tokens. Use a standards-aware HTML checker and browser testing for conformance and behavior.

Why did spaces in visible text change?

The formatter collapses whitespace runs in ordinary text tokens and trims some boundaries near block tags. HTML and CSS may make those spaces meaningful, so inspect the rendered result.

Are <script> and <style> contents formatted?

Yes, with lightweight brace and punctuation rules. They are not processed by full JavaScript or CSS parsers.

Can comments be preserved?

Yes. Keep Comments is on by default. Turning it off removes recognized comments only from output.

Does attribute wrapping put exactly one attribute per line?

For tags split successfully by the attribute matcher, recognized attribute pieces are emitted on separate indented lines. Complex framework syntax may not split cleanly.

Are custom elements treated as blocks?

Not by default. The block behavior comes from a fixed list of standard tag names; an unlisted custom element follows inline handling.

What does Download save?

It saves the current output as formatted.html with the text/html media type.