What the formatter changes — and what it refuses to
It changes indentation in element-only regions, the layout of attributes inside start tags, and — only when you ask — quote characters, attribute order and empty-element style. Each normalisation is counted and reported in Findings.
It refuses to touch character content. The DocBook sample above shows why: the paragraph contains two emphasised phrases separated by a single space, and the program listing is under xml:space="preserve". Both are copied exactly.
Attribute layouts
“Wrap when long” keeps a start tag on one line until it would pass the width limit, then puts each attribute on its own line. “Aligned” lines attributes up under the first one. “One per line” always splits tags with two or more attributes, which keeps code-review diffs small. “Keep as written” leaves start tags exactly as they are.
Sorting attributes is explicit and namespace-aware: the order is by namespace URI and local name, so two attributes with different prefixes can never collapse into a duplicate.
Questions
Is the output deterministic?
Yes. The same input and options always produce the same bytes. Options can be saved as a versioned recipe on the Presets page and shared as plain JSON.
Does it keep comments and processing instructions?
Yes, in their original position and order. Only the minifier can remove comments, and only when you tick that option, which is reported as information loss.
What happens with CRLF line endings?
By default the formatter keeps the line-ending style it detects. You can force LF or CRLF; text inside protected regions keeps its original line endings either way.