Format, minify, and validate XML — locally, in your browser
| Rule | Requirement | Example of a violation |
|---|---|---|
| One root element | The document has exactly one top-level element (after the optional declaration and comments) | <a/><b/> |
| Every tag closed | Each open tag has a matching close tag, or is self-closing | <a><b></a> |
| Proper nesting | Elements close in reverse order of opening | <a><b></a></b> |
| Case-sensitive names | <Item> and <item> are different elements | <item></Item> |
| Quoted attributes | Attribute values use single or double quotes | <a id=1> |
| Escaped entities | & < in content use entities; the other three are situational but always-safe | <name>A & B</name> |
| Declaration first | <?xml version="1.0" encoding="UTF-8"?> if present, must lead the file with no leading whitespace | blank line before the declaration |
The five predefined entities: < > & " '. Common MIME types: application/xml (preferred), text/xml. UTF-8 is the default encoding when the declaration omits it.
Formatting isn't find-and-replace. The tool parses your XML into a tree, then re-serializes that tree with a consistent layout: one element per line, each level of children indented one stop, attributes untouched, and text nodes kept on the same line as their parent when the collapse-content option is on. Because the output comes from the parsed tree — not string surgery — the structure of the document is guaranteed unchanged.
Take a small two-entry feed document. Pretty-printed at 2-space indentation it runs 563 bytes across 20 lines. Minified, the same document runs 477 bytes — a 15.3% reduction for deleting nothing but whitespace. Round-tripping proves the structure survived: formatting the minified version reproduces the original pretty document line-for-line — 563 bytes in, 562 out, the only casualty being the trailing newline. Parsing it also yields the stats: 14 elements, 9 attributes, and a maximum nesting depth of 4 (feed → entry → categories → category).
How much minification saves depends entirely on how much indentation the document starts with. The feed above carries one indent level per nesting depth; a machine-generated file with 8-space depth-8 indentation can shrink by half. Already-dense XML barely moves.
The surprise for most people: it depends on the data shape. The 477-byte minified feed converts to 755 bytes of compact JSON — 37% larger — because JSON repeats every key name for every record ("title" appears twice verbatim), while the XML hangs short facts on attributes. JSON wins on documents where elements are mostly containers; XML wins when attributes carry the payload. Never assume — measure both.
This tool checks well-formedness: the syntax rules in the table above. When parsing fails, you get the parser's position — line and column — for the first problem, which is usually a mistyped close tag or an unescaped ampersand. Full validity (against an XSD or DTD schema) is a different check that needs your schema file; CI pipelines and IDEs with the schema on disk handle that stage.
Formatting and minification use xml-formatter 3.7.0 (with xml-parser-xo); strict validation uses xml-js 1.6.11 — all MIT/BlueOak licensed, bundled into two files under /vendor with their license texts. Everything runs client-side.
Paste the XML and pick an indentation — 2 or 4 spaces, or tabs. The formatter parses the document and re-emits it with one element per line, children indented one level under their parents, and text content kept inline when collapse-content is on. It's a re-serialization of the parsed tree, so the structure is guaranteed identical.
Well-formed means the syntax parses: one root element, every tag closed, proper nesting, attributes quoted, entities escaped. Valid goes further — the document also obeys a schema (DTD, XSD, or RelaxNG) that defines which elements and attributes are allowed where. This tool checks well-formedness; schema validation needs your XSD, which usually lives next to your build pipeline.
It depends on how much indentation and whitespace the document carries. A realistic 20-line feed document drops from 563 bytes to 477 bytes — a 15.3% reduction. Machine-generated XML with deep indentation can shrink 40% or more; already-dense XML barely moves. Minified XML is functionally identical to the pretty version.
Five characters have predefined entities: < becomes <, > becomes >, & becomes &, " becomes ", and ' becomes '. Strictly, < and & must be escaped everywhere; > " and ' only need escaping in certain positions, but escaping all five is always safe. CDATA sections are the alternative for blocks of raw text like embedded code.
Neither, universally. XML's closing tags add bytes that JSON doesn't have, but JSON repeats key names for every record while XML can hang repeated data on attributes. On a sample feed document, minified XML runs 477 bytes while the equivalent compact JSON runs 755 — the XML is 37% smaller because short attribute names beat repeated JSON keys. Measure both on your actual payload.