HTML formatter that renders the same afterwards

Because most formatters treat a document as a tree of tags and forget that inside <pre> the whitespace is the content. Adding two spaces to every line of a code sample shifts the code sample; wrapping a long line inside <pre> puts a line break into the text a reader sees. This formatter never touches the inside of a <pre> or a <textarea>: the start tag, everything between it and the end tag, and the end tag are copied out as one run of characters, and the counter tells you how many such regions it left alone.

Not here, and this is the whole reason the rest of the rules exist. In normal white-space mode a browser collapses a run of whitespace to a single space and renders it, so putting a line break between </span> and <span> where the source had none turns ab into a b — a visible change, and a well-known cause of gaps between inline-block cards and stray spaces in a breadcrumb trail. The rule followed here is that a line break may only be introduced where whitespace already existed, or beside a block-level element where whitespace cannot render at all. Forty elements are treated as inline, img, button, label and svg among them.

Because HTML lets you leave some of them out, and the browser inserts them anyway — so the formatter writes down the tree the browser will build rather than the text you typed. Fourteen elements have optional end tags: a second <li> closes the first, a <tr> closes the open <td>, and a <p> is closed by any of 26 block elements that cannot legally sit inside it. Writing them out is not a change to the page; it is the same DOM with the shape made visible. If you prefer them absent, delete them afterwards — the parse is identical either way.

They are handed to the JavaScript and CSS printers this site already runs, then indented one level in from their tag. A <script type="application/ld+json"> block goes to the JSON parser instead, so your structured data comes back as a readable tree. Anything those readers refuse — a template language in a script tag, a half-finished function, a CSS block with an unbalanced brace — is copied out exactly as written and named in the report underneath. A block is never partly formatted.

No, and that is a correctness decision rather than a preference. HTML tag names are case-insensitive, but SVG and MathML live in the same document and are not: lowercasing <linearGradient> or the viewBox attribute breaks the graphic, and React's markup carries camelCase attributes for the same reason. Nothing is lowercased, no quotes are added or removed around attribute values, and no attribute is reordered — the text of each attribute is copied across whole.

Partly, and it says which part. A <?php … ?> or <% … %> fragment is copied out verbatim as a single unit, so the code inside it is never re-spaced, and moustache expressions in text are ordinary text. What the reader does not do is understand template control flow: a {{#if}} block that opens in one element and closes in another has no tree for the indenter to follow, so the surrounding markup is indented by the real tags and the template directives ride along where they sit. Attribute syntax such as :prop, @click and v-if is preserved exactly, since attributes are copied rather than parsed.

It closes it at the end of the document and tells you so, which is what a browser does. An unclosed <div> means everything after it is nested inside it, so the output is deeply indented and the note under the tool names the element — that indentation is the bug becoming visible rather than the formatter misbehaving. A closing tag with nothing to close is left exactly where it was found and reported, because deleting markup is not a formatter's job.