What the formatter does
This XML formatter reindents a document with 2 spaces, 4 spaces or tabs, or flattens it to a single line, without leaving your browser. It is a hand-written tokeniser rather than the browser's parser, so the same code runs under test: it walks declarations, DOCTYPE lines, comments, processing instructions, CDATA sections, tags and text, then rebuilds the file from what it found.
Attributes are put back one space apart with proper quoting, so a tag spread over five lines becomes one readable line. When something does not close, you get the line, the column and the name of the tag that went wrong.
XML did not go anywhere
It is easy to believe the format died in 2012. It did not, and the places it survives are places nobody gets to opt out of.
Every sitemap Google reads is XML, and so is every RSS and Atom feed. Android lays out its screens
and declares its permissions in it. Maven, Ant and NuGet describe builds in it. SOAP still moves
money between banks and insurers, and the government and healthcare integrations built around it are
measured in decades. Office documents — .docx, .xlsx — are zipped folders of it. SVG is it.
None of that is nostalgia. It is why a working formatter is still a tool people reach for, usually at the moment a feed will not validate or a build file has been merged badly.
Whitespace is not decoration
The rule that trips people is that XML has no way to know which spaces you meant. Between two tags, whitespace is almost always layout. Inside a run of text, it is content. A formatter that treats both the same will quietly edit your document.
So this one draws the line the same way a careful hand would. Whitespace-only text between elements
is layout and gets replaced by the new indentation. An element holding one run of text has that text
trimmed at the ends and pulled onto the tag's line. But an element with text beside a child tag is
left alone completely, on a single line, because there is no safe way to add newlines to a sentence.
And xml:space="preserve" disables all of it for that subtree, which is the attribute's whole
purpose.
CDATA, and when to use it
A CDATA section is an escape hatch: everything between the delimiters is text, so < and & lose
their meaning and need no escaping. That makes it the right home for an embedded script, a chunk of
HTML inside a feed, or a SQL fragment in a config file.
It is not a magic quote. The one sequence it cannot contain is its own terminator, and a section holding untrusted content is a real injection route in feed readers. Content inside one is copied through here untouched, and its presence stops the surrounding element from being reindented.
XML against JSON, without the sermon
JSON won for APIs because it maps onto the data structures of every language with no ceremony, and because it has one obvious way to write most things. For a payload between two services, that is the whole argument.
XML earns its weight where documents, not records, are the subject. Attributes distinguish metadata from content. Namespaces let two vocabularies share a file without colliding. Schemas, XPath and XSLT are mature in a way the JSON equivalents still are not, and mixed content — text with markup inside it — has no natural JSON representation at all.
Choose by shape of the problem, not by year. If you are moving between the two, the JSON formatter handles the other side, and the JSON to TypeScript converter will type a payload once you have it.