Format XML takes raw, minified, or inconsistently indented XML and rebuilds it with clean, predictable 2-space nesting — or strips it down to a single compact line when you need the opposite. It also acts as a well-formedness validator: if the XML has a syntax problem, the browser's own XML parser reports it immediately instead of silently producing garbage output.
XML has been the backbone of enterprise data exchange since the late 1990s, and despite JSON taking over as the default choice for web APIs, XML remains heavily used in places JSON never displaced it: SOAP web services, Android manifests and layout files, Maven and Ant build configuration, Microsoft Office's underlying file formats (.docx and .xlsx are ZIP archives full of XML), RSS and Atom feeds, sitemap.xml files, and countless legacy enterprise systems in finance, healthcare (HL7), and government that standardized on XML decades ago and have no reason to migrate. If you work anywhere near those systems, you will eventually receive an XML payload crushed onto one line by a server response or a database export, and reading it in that state is close to impossible.
What makes XML formatting slightly trickier than JSON formatting is that XML allows mixed content models, self-closing elements, namespaces, comments, and CDATA sections, none of which JSON has to worry about. A naive regex-based formatter that just inserts a newline after every > will mangle attribute values that happen to contain a > character, or will misindent an element that legitimately mixes text and child elements. This tool avoids that by using the browser's native DOMParser to build a real parse tree first, then walking that tree recursively to emit indentation — the same parser Chrome and Firefox use internally, so if your XML parses here, it will parse the same way in production code that uses DOMParser or a server-side XML library.
Because parsing happens through DOMParser, this tool also functions as a fast well-formedness check. XML parsing is strict by design — unlike HTML, an XML parser will not attempt to guess your intent around an unclosed tag or an unescaped ampersand, it will simply fail with a parser error. That strictness is a feature: catching a malformed tag here, in a second, is much cheaper than discovering it after a build pipeline or API integration chokes on it downstream.
Need to check it against a schema rather than just well-formedness? Validate XML with XSD handles that stricter check, and Generate Sitemap produces a fresh sitemap.xml from scratch.
