HTML Formatter

Most HTML tolerates a formatter reflowing its whitespace freely — extra indentation between block-level elements like `<div>` and `<p>` has no visible effect, because browsers collapse runs of whitespace between such elements when rendering. Three specific cases break that assumption entirely: content inside `<pre>` renders every space and line break literally, exactly as written; `<textarea>` treats its content the same way since it is meant to reproduce exact user-editable text; and any element carrying `white-space: pre` in CSS inherits the same literal treatment. A formatter that reflows whitespace inside any of those blocks changes what the page actually displays, not just how the source looks — which is why this formatter leaves them completely untouched rather than applying its usual indentation rules.

Inline elements sitting directly next to text are a subtler case: a space between two inline elements is sometimes visually significant — the gap between two words spanning separate `<span>` tags, for instance — so the formatter is deliberately conservative around inline content, preferring to leave ambiguous whitespace as-is rather than risk collapsing a space that was doing real visual work.

A page assembled as a single HTML file commonly embeds its own CSS inside a `<style>` block and its own JavaScript inside a `<script>` block, and a formatter that only understands HTML tags would either leave that embedded code as an unformatted blob or, worse, mangle it by treating curly braces and semicolons as HTML syntax. Handing the content of those blocks off to a real CSS parser and a real JavaScript parser respectively means the whole file — markup, styles and behaviour together — comes back consistently formatted, rather than only the outer HTML structure.

Browsers are built with an error-recovery model specifically designed to render something reasonable even from badly malformed markup — an unclosed tag, a missing quote, elements nested in an invalid order — because the web has decades of imperfect HTML in production that still needs to display. A formatter cannot adopt that same leniency: to reformat a document it has to build an accurate structural understanding of what is nested inside what, and a document with genuinely unbalanced tags has no single correct structure to recover. This is why a page that displays completely normally in a browser can still be rejected by this formatter — the browser silently repaired the ambiguity in its own way, while a tool trying to reformat correctly has to flag the ambiguity rather than guess.

A file that fails to format is very often not broken HTML at all, but a template — Handlebars, Jinja, Blade, EJS or similar — that mixes templating directives with markup, producing a document that is not valid standalone HTML on its own and never needs to be. The template only becomes real, well-formed HTML after its templating engine has run and substituted in the actual data. Formatting the rendered output, captured after the template engine processes it — from a browser's "View Source," for instance — sidesteps this entirely, since that output is real HTML with no templating syntax left in it.