XML Formatter & Viewer

What this XML formatter does

XML is readable by design, but almost never arrives that way. API responses, SOAP envelopes, sitemaps and export files ship minified — one line, thousands of characters, no indentation. This tool re-inserts the structure: it parses the document, rebuilds it with consistent indentation, and renders it as a tree you can collapse branch by branch to find what you actually need.

Everything runs locally

The parsing uses DOMParser, the XML engine already built into your browser — the same one that renders every web page you open. There is no upload step and no server round-trip. That matters more than convenience: XML files routinely carry invoices, patient records, payroll data and API tokens. Pasting those into a tool that uploads them to a third party is a data leak, even when the tool is well-intentioned. Here the file never leaves the tab.

Formatting vs. minifying

One caveat worth knowing: whitespace inside a text node can be significant. In <name> Ana </name> those spaces are part of the value, and a strict consumer may treat them as such. This formatter preserves text-node content untouched and only reformats the space between elements, which is where indentation is safe.

What “valid” means here

XML has two distinct levels of correctness, and mixing them up is the most common source of confusion when a file gets rejected downstream:

• Well-formed — syntax is legal. Exactly one root element, every tag closed in the right order, attribute values quoted, and the five reserved characters (< > & " ') escaped. This is what we check, and the error message points at the exact line.
• Valid — the document also conforms to a schema (XSD, DTD or RELAX NG) that dictates which elements may appear, in what order, and with which data types. That requires the schema file itself and a dedicated processor; no browser does it natively.

So a file can format cleanly here and still be refused by the system that consumes it — that rejection is a schema problem, not a syntax problem.

Common errors and what they usually mean

• “Extra content at the end of the document” — two root elements. Usually happens when someone concatenates several responses into one file. Wrap them in a single parent element.
• “EntityRef: expecting ';'” — a bare & in text or in an attribute, typically inside a URL with query parameters. It must be written as &.
• “Opening and ending tag mismatch” — a tag closed out of order, or closed with different capitalization. XML is case-sensitive: <Item> and <item> are different elements.
• Invalid character errors — a stray control character or a byte-order mark in the middle of the file, common when a file has been through several encodings.

Namespaces, and why a prefix is not a name

Namespaces are where XML stops being intuitive. A prefix like soap: or xsi: is not the identity of the element — it is a local shorthand that points at a URI declared somewhere above it with xmlns:. Two documents can use completely different prefixes for the same namespace and be identical as far as any XML processor is concerned.

That has a practical consequence people run into constantly: you cannot reliably search a SOAP response for <soap:Body>, because the sender is free to call it <env:Body>. What identifies the element is the pair (namespace URI, local name), not the text of the prefix.

The default namespace is stricter than it looks. Declaring xmlns="http://example.com/ns" on an element puts that element and every unprefixed descendant into that namespace — but it never applies to attributes. An unprefixed attribute is always in no namespace, whatever the default is. This is the single most common namespace bug, and it produces XPath expressions that match nothing while looking obviously correct.

Formatting here preserves declarations exactly where they were. Moving a xmlns to the root to tidy things up would change which elements it covers, so we never do it.

CDATA, entities and whitespace that actually matters

A CDATA section tells the parser to treat everything inside as literal text. It exists so you can embed markup — an HTML fragment, a snippet of code, a JSON payload — without escaping every angle bracket. Inside CDATA, no entity is expanded and no tag is recognised.

It has exactly one thing it cannot contain: the sequence ]]>, which ends the section. There is no escape for it. The only fix is to split the content into two adjacent CDATA sections at the offending point, which is genuinely awkward and is why deeply nested content is usually escaped instead.

Whitespace is the other trap. XML has no general rule that spaces between tags are insignificant — that is a convention of the schema, not of the format. Indenting a document is safe for element-only content, but adding a newline inside a text node changes the value of that node. This formatter only adds indentation between elements and leaves text nodes untouched, which is why a formatted document and the original are equivalent for every consumer that respects the same convention.

The five predefined entities are <, >, &, " and '. Everything else —   in particular, which people bring over from HTML — is undefined in XML unless the document declares it, and it is a hard parse error rather than a warning.

XML compared with JSON and YAML

XML is verbose, and that is the honest trade. What it buys is expressiveness JSON does not have: comments survive, an element can carry both attributes and children, the same element name can repeat without becoming an array, and mixed content — text with markup inline, the way a document actually reads — has no clean JSON equivalent.

Which is why XML did not go away where documents are the subject: RSS and Atom feeds, SVG, Office and OpenDocument files, Android layouts, Maven builds, SOAP services, SAML assertions and most government and banking interchange formats are all XML, and will be for a long time.