XML Formatter

A formatter built on regular expressions — inserting a newline before every `<` and indenting based on a running count of open tags — works passably on simple, hand-written XML and fails on real-world documents for reasons that are easy to overlook until they cause a corrupted file. A CDATA section, written as `<![CDATA[...]]>`, exists specifically to hold arbitrary text that might itself contain characters that look like tags, and a regex scanning for `<` has no way to know it should ignore everything between those markers rather than treating the contents as structure. Comments carry the same risk, and attribute values are worse still: an attribute like `note="a > b"` contains a literal `>` character that a naive scanner can mistake for the end of the tag, silently truncating it in the wrong place.

Correctly formatting XML means the scanner has to recognise these special regions — CDATA blocks, comments, processing instructions, DOCTYPE declarations, and quoted attribute values — before it looks for anything resembling tag structure, so their contents are carried through byte-for-byte rather than being reinterpreted as markup.

This tool checks that every tag is properly closed and correctly nested — the structural rules that make a document "well-formed" XML — and reports the specific mismatched or unclosed tag when that check fails. What it does not do is validate the document against a DTD or an XML Schema (XSD), which would additionally check whether the specific elements, attributes and their values conform to a particular document type's rules — whether a required attribute is present, whether an element appears in the right context, whether a value matches an expected data type. That is a genuinely different and more involved check requiring the schema document itself as an additional input, not something a general-purpose formatter can infer from the XML alone.

Strict XHTML is valid XML and formats correctly here, but ordinary real-world HTML is not, for reasons built into the HTML specification itself: void elements like `<br>` and `<img>` are never closed and have no closing tag at all, several tags have optional closing tags that browsers infer automatically, and browsers tolerate malformed nesting that strict XML parsing would reject outright as an error. An XML-strict formatter applied to typical HTML would report errors on every well-formed, completely normal page, which is precisely why HTML gets a separate formatter built around an actual HTML parser that understands these HTML-specific rules rather than treating the document as strict XML.

JSON has replaced XML as the default choice for new web APIs, but a great deal of infrastructure was built before that shift and still runs on it: SOAP web services, RSS and Atom feeds, SVG images (which are themselves XML), Office document formats internally, and a long tail of enterprise systems and configuration formats that predate JSON's popularity. Anyone integrating with one of these older or more formal systems still needs to read, debug and produce well-formed XML, which is precisely the audience a dedicated XML formatter continues to serve even as XML has receded from new API design.