HTML Formatter
The whitespace you add when indenting is not always invisible
Under the default white-space: normal, HTML collapses a run of whitespace into a single space. It does not delete it. Between two inline-level elements that surviving space is rendered, so putting two <span> tags on their own indented lines can open a gap that was not there in the one-line markup. For the overwhelming majority of markup, indenting is safe and the page is identical. This is the case where it is not, and it is worth knowing before you reformat a template that is already in production.
Where re-indenting shows up on screen
- Inline-level elements that must touch:
<span>,<a>,<img>,<button>sat next to each other. - List items or cells set to
display: inline-block, where the gap between them comes from the source file rather than from any CSS rule. <pre>and<textarea>, where spaces and newlines are preserved and shown, so indenting their contents changes what the reader sees. The one thing the parser does drop is a single newline immediately after the opening tag.
If a layout shifts after formatting, that is almost always the cause. The fix is to remove the whitespace in the source, or make the parent a flex or grid container, since a text run that is only whitespace generates no flex or grid item.
Void elements never get a closing tag
Indented markup makes unclosed tags obvious, and people then close things that should stay open. <br>, <img>, <input>, <meta>, <link> and <hr> are void elements: they take no end tag in HTML, so an unclosed one is correct. A trailing slash on them is permitted and the HTML parser ignores it; it carries meaning in XHTML, in inline SVG or MathML, and in JSX.
Minifying is not the same as compressing
Stripping indentation makes the file smaller, but most servers and CDNs already send HTML through gzip or brotli, and those algorithms handle repeated whitespace very well. Minified and formatted copies of the same document end up far closer in transferred size than their raw sizes suggest. Doing both is normal practice; treating minification alone as a performance strategy is not.
Use the indented output for reading and reviewing instead. A minified template is unreadable in a pull request, while a formatted one gives you line-level diffs. Formatting is also not validation: this tool will not tell you about misnested tags, duplicated attributes or a reused id, and the output still looks tidy either way.
Share this tool with friends
Free to use, no sign-up, works on any phone.
Frequently Asked Questions
For block-level structure, no: the extra indentation collapses and nothing moves. The exception is inline content, where a run of whitespace between two inline-level elements collapses to a single space that is genuinely rendered, so splitting them onto separate lines can open a visible gap. Content inside pre and textarea is preserved as written, so reindenting it changes what is displayed. Check those two cases after formatting anything already live.
That space comes from your source file, not from CSS. Whitespace between two inline-level elements — spans, links, images, buttons, inline-block list items — collapses to one space, and that space is rendered. If the elements must sit flush, either remove the whitespace in the markup or make the parent a flex or grid container, because a text run that is only whitespace generates no flex or grid item at all.
The gain is much smaller than the raw byte counts suggest, because gzip and brotli already compress repeated whitespace very effectively. Minifying on top of compression is normal practice and usually shaves a little more off the transferred size, but it is a marginal win rather than a performance strategy. Do both if you like, and do not expect minification alone to fix a slow page.
No. These are void elements, along with meta, link, hr and a few others, and they take no end tag in HTML — an unclosed one is correct, not a bug. A trailing slash before the bracket is permitted and the HTML parser ignores it; it carries meaning in XHTML, in inline SVG or MathML, and in JSX. Writing a separate end tag is invalid: most are simply ignored, but a closing br tag is a special case that the parser turns into an extra line break.
No. It re-indents or minifies markup; it does not validate it. Misnested tags, duplicated attributes, a reused id or a missing required attribute are not reported, and the output will still look neatly structured. Tidy formatting and valid HTML are separate questions, so run a validator if correctness is what you are checking.
Whitespace inside pre and textarea is significant and is displayed as written, so reindenting their contents changes the rendered output, usually as extra leading spaces on every line of a code sample. The only whitespace the parser discards is a single newline straight after the opening tag. If the rendered result matters, keep those blocks flush left in the source and compare before and after.