Why the parser matters
HTML formatting is not indentation. <span>a</span> <span>b</span> renders with
a space between the words; putting those spans on separate lines with an indent
keeps the space, but <span>a</span><span>b</span> does not have one and adding
a newline creates it. A formatter that does not model this changes the page.
This uses Prettier's HTML parser, which tracks inline versus block context and whitespace sensitivity per element. That is also why it refuses to format markup it cannot parse instead of producing something plausible.
What is left alone
<pre>, <textarea>, <script> and <style> keep their contents unchanged.
In the first two whitespace is visible to the reader; in the last two it belongs
to another language entirely.
Formatting before committing
The practical value is diffs. Consistently formatted markup means a review shows what actually changed rather than a wall of re-indentation, and it removes a whole category of pointless argument from code review.
Questions
Can formatting change how the page renders?+
In HTML, yes — whitespace between inline elements is rendered. Prettier knows which elements are inline and where a space matters, which is why this uses it rather than a naive indenter. Blocks are reflowed freely; inline runs are treated carefully.
Is pre and textarea content safe?+
Yes. Whitespace inside them is content, and both are left byte for byte. The same applies to script and style bodies.
Why did my attributes end up on separate lines?+
Prettier wraps when a tag exceeds the print width. It is a deliberate, stable rule — the same input always produces the same output, which is what makes formatted HTML diff cleanly.
Does it fix broken markup?+
No, and it should not. Unclosed tags and mismatched nesting are reported as a parse error rather than guessed at. A formatter that silently repairs markup hides the bug you needed to see.