Menu

HTML Formatter

HTML Formatter: How It Works

An HTML formatter re-indents markup so its structure becomes visible. That is useful for reading, and more useful for diagnosis: the point where indentation stops making sense is almost always the point where a tag was left unclosed.

What formatting reveals

Browsers are extraordinarily tolerant. Give one a missing </div> and it will silently repair the document, producing a structure that renders — just not the structure you wrote. The result is layout that breaks in one browser, styles that apply to the wrong elements, or JavaScript selectors that find nothing.

Formatting exposes this immediately. When indentation runs away to the right and never comes back, an opening tag was never closed. When a block ends earlier than expected, something closed too soon.

Void elements

Some elements never have closing tags: area base br col embed hr img input link meta source track wbr. In HTML5 the self-closing slash is optional and has no effect — <br> and <br /> are identical. Consistency matters more than which you choose; JSX and XHTML require the slash, plain HTML does not.

Where whitespace changes rendering

Formatting is not always cosmetically neutral.

ContextEffect of added whitespace
<pre> and <textarea>Preserved and displayed — never reformat inside these
Inline elementsWhitespace between them becomes a visible space
inline-block layoutsGaps appear between items
Table cellsGenerally collapsed harmlessly

The inline-block gap is the classic case: reformatting a horizontal list of items suddenly introduces four-pixel spaces between them. Flexbox and grid layouts are immune, which is one more reason to prefer them.

Attribute conventions

Formatting is not validation

A formatter indents whatever it is given. It will not tell you that a <div> sits inside a <p>, that an <img> lacks alt text, or that heading levels skip from h2 to h4. Run a validator alongside — the W3C service catches structural and semantic problems a formatter cannot see, and accessibility issues that neither will surface without a dedicated checker.

Formatted or minified in production

Serve minified HTML and keep the formatted version as your source. As with JSON, compression captures most of the size benefit, so the case for minifying HTML specifically is modest — but there is no reason to ship indentation to a browser either. Any build pipeline handles this automatically; the important part is that the readable version is the one your team edits.

Frequently Asked Questions

Will formatting change how my page renders?
Usually not, with two exceptions. Whitespace inside pre and textarea elements is displayed, so those must never be reindented. And whitespace between inline or inline-block elements becomes a visible gap.
Do I need to close tags like <br> and <img>?
No. These are void elements with no closing tag, and in HTML5 the self-closing slash is optional and has no effect. Pick a convention and apply it consistently — JSX and XHTML require the slash.
Why does my layout break after formatting?
Almost always the inline-block gap: whitespace introduced between elements renders as a space of roughly four pixels. Switching the container to flexbox or grid eliminates it permanently.
Does a formatter validate my HTML?
No. It indents whatever it receives, valid or not. Use a validator such as the W3C service for structural problems, and a dedicated accessibility checker for missing alt text and heading order.
Should I minify HTML in production?
It does no harm, but with compression enabled the additional saving is small. Keep the readable version as your source and let a build step handle minification if you use one.
How do I find a missing closing tag?
Format the document and look for where indentation runs away to the right without coming back. That drift begins at the unclosed element, which is far faster than reading the markup line by line.

Related Developer Tools

Browse all Developer tools →