HTML Beautifier

HTML beautifier: void elements, whitespace sensitivity, and spaces between inline elements

Formatting must know which tags are void elements

HTML has a set of void elements — they cannot contain content and have no closing tag. The formatter must know this list, or it will attach a wrong closing tag and break the structure:

Writing <br></br> is invalid (the HTML parser ignores that closing tag, but it is an error under XHTML syntax). Likewise, attaching a closing tag to <img> makes the resulting DOM diverge from what you expect — this is a classic cause of "the page broke after formatting".

Also note that the contents of <script>, <style>, <pre>, and <textarea> are raw text and must not be re-indented. Inserting a space into <pre> changes what is displayed; inserting one into <textarea> changes the initial value the user sees. This tool keeps the inside of those elements exactly as-is.

Whitespace in HTML is sometimes meaningful

This is the most overlooked risk of formatting. HTML normally collapses a run of whitespace into a single space, but collapsing does not mean you may freely add or remove newlines:

So: splitting an icon and its label onto separate lines can add a stray space, shifting a button's width or wrapping its text. Watch navigation bars and button groups especially. These problems are invisible in development and only appear in production at certain fonts or zoom levels.

Two ways to avoid it: keep inline elements on one line (compact writing), or use CSS techniques such as display: flex or the older font-size: 0 trick (the latter needs the font size restored on children). Modern projects prefer the former, or go straight to Flex/Grid layout so whitespace stops affecting layout.

Other formatting constraints

• Attribute quotes. A value may be quoted whether or not it contains spaces, and formatting should add quotes uniformly (an unquoted value may not contain spaces, quotes, equals signs, and so on). Values with special characters must be quoted and must escape & and the quotes themselves.
• Comments. An HTML comment may not appear inside a tag (something like <div <!-- x --> > is invalid), nor may it contain a -- sequence (a historical parsing limit). The formatter must be careful around comments.
• DOCTYPE must come first. It is the only content legally allowed before <html>; any whitespace or comment before it pushes the browser into quirks mode, breaking CSS behaviour.
• HTML and XHTML syntax differ. XHTML requires every tag closed, attributes quoted, and tag names lowercase. Treating an HTML fragment as XHTML (or vice versa) produces incompatible output.
• Formatting does not repair syntax errors. A missing closing tag is not auto-added — the browser will infer one (possibly wrongly) at parse time, but the formatter merely re-indents text. It does none of an HTML parser's error tolerance.

How to use the tool

Paste the HTML source, click format, and the output indents by tag level while keeping the contents of script, style, pre, and textarea intact. It suits tidying minified code copied from "view source", checking tag nesting depth, and unifying format before a commit.

The reordering happens in your browser; nothing is uploaded. Remember formatting is a text-level reordering, so before committing to a project, confirm in a browser or validator that the rendered result did not change — especially for fragments heavy with inline elements.