When is XML Formatter useful?
XML formatters are usually needed after a machine has written the file. A build step, a SOAP client, or an export from a content system tends to produce either one enormous line or indentation that changes halfway through the document. Putting every element on its own line with consistent indentation makes the structure visible and makes a diff between two versions readable. The document is parsed and written back inside the tab, so a file that carries configuration or customer data does not make a round trip to a server.
Formatting keeps the content and changes only the whitespace. An element that has children is written on its own line and its attributes are split one per line, indented four spaces past the element, which is what makes a record with a dozen attributes readable. An element that holds only text stays on a single line, because breaking a short value across three lines would add nothing. An element with no children and no text collapses to a self-closing tag. The declaration is written once at the top and the output always uses two spaces per level.
The page checks well-formedness, not validity. A missing closing tag, an unquoted attribute, or a stray ampersand is reported with the line and column from the parser, and no partial output is produced, so a broken document never looks like a formatted one. It does not consult a DTD or a schema, so an element in the wrong place passes without comment. Comments are kept, character data is escaped correctly, and namespaces are written back exactly as they were read. A very large document is still handled in one pass, so the tab may pause while it runs. Formatting does not reorder attributes, does not drop the declaration, and does not rewrite entity references, so a diff taken after formatting shows only real content changes.