XML Formatter & Validator
Pretty-print, minify and validate XML — no upload, no account, works on any well-formed document.
Your XML never leaves this tab — safe for production feeds and configsFormat, minify and validate XML — with namespaces, CDATA and mixed content
About this XML formatter and validator
Paste an XML document, click Format for indented output, Minify for a single line, or Validate for a well-formedness check with element / attribute / depth counts. The pretty-printer respects mixed content — a paragraph like <em>Hello <b>world</b>!</em> stays on one line rather than being shredded across three — and keeps attributes in their original source order with their namespace prefixes intact. If the input is malformed, the parser returns a specific error with the location, not just "invalid XML".
Under the hood, the tool uses the browser's built-in DOMParser to parse the document and a hand-written serializer to walk the resulting DOM and emit the formatted text. That means everything runs locally: your XML — which for a lot of workloads means SOAP payloads, RSS feeds, Excel .xlsx innards, SVG documents or Android resource files — never leaves this tab. There is no upload endpoint to compromise, no server logs to audit, and no daily limit.
The formatter handles the five XML node types you will actually see: elements (with any level of nesting and any number of attributes), text (including CDATA sections for content that would otherwise need escaping), comments, and processing instructions like <?xml-stylesheet?>. The XML declaration itself is preserved from the input and emitted at the top of the output, because the DOM API strips it on parse — a subtle bug that trips a lot of naive formatters.
A common question: what counts as "well-formed"? The XML spec draws a hard line. Every element must be closed, tag names are case-sensitive, attributes must be quoted, entities must be defined or use the five predefined ones (& < > " '), and the document must have exactly one root element. Well-formedness is the entry-level bar — a document that fails it cannot be processed by any XML tool. What this validator does NOT check is validity against a specific schema (DTD, XSD or RELAX NG); that is a separate stage and typically needs the schema file too.
The output uses two-space indentation by default, matching the convention that XML consumers and most editors expect; four spaces or tab are one dropdown away for teams that prefer them. The indentation is significant only for readability — every XML parser strips it — so whichever setting you pick will produce byte-identical parses.
Well-formed XML — the checklist
Every issue this tool will flag traces back to one of these rules. If a document passes them, it can be parsed by any XML consumer; if it fails, it fails everywhere.
| Rule | What breaks it | The fix |
|---|---|---|
| Every element closes | <p>Hello — no </p> | Close it: <p>Hello</p> — or self-close if empty: <br/> |
| Tag names match case | <Item>...</item> | Match the case: <Item>...</Item> |
| Attributes are quoted | <a href=foo> | Quote: <a href="foo"> or <a href='foo'> |
| Attributes are unique per element | <a class="x" class="y"> | Use one attribute, or a space-separated list |
| Entities are predefined or declared | <p>M&Ms</p> | Escape: <p>M&Ms</p> |
| Exactly one root element | Two top-level <item>s with no wrapper | Wrap them: <items><item/><item/></items> |
| Reserved characters escaped in text | <code>a < b</code> | <code>a < b</code> or use CDATA |
The five predefined entities
| Character | Entity | When you need it |
|---|---|---|
| & | & | Always — even inside attribute values |
| < | < | In text content, always. In attribute values, always |
| > | > | Optional in text, but idiomatic; required after "]]" to avoid the CDATA-end sequence |
| " | " | Inside double-quoted attribute values |
| ' | ' | Inside single-quoted attribute values |
These five are the only entities that work in every XML document without a DTD declaration. Anything else — , ©, € — is HTML, not XML; either declare it in a DTD, use its numeric form ( ), or wrap the text in a CDATA section.
When to use CDATA
A CDATA section tells the parser "treat this content as literal text, do not interpret markup or entities inside it." Use it when the text contains many characters that would otherwise need escaping — a code snippet, a shell command, a chunk of SQL, JavaScript, or HTML being carried inside an XML envelope.
Without CDATA — every < has to be escaped:
<query>SELECT * FROM users WHERE age < 18 AND active = "yes"</query>
With CDATA — write it as-is:
<query><![CDATA[SELECT * FROM users WHERE age < 18 AND active = "yes"]]></query>Namespaces in one paragraph
A namespace lets two vocabularies share the same document without their tag names colliding — the classic case being a SOAP envelope that carries an app-specific payload. The xmlns attribute declares a URI (which is just an identifier, not a URL that gets fetched) and either binds it to a prefix or sets a default:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getOrder xmlns="urn:example:orders">
<id>A-10482</id>
</getOrder>
</soap:Body>
</soap:Envelope>Prefixes are just aliases — the URI is what actually identifies the namespace. Renaming soap: to s: would make no semantic difference as long as the same URI is bound. This formatter preserves prefixes exactly as they appear in the input.
Rest of the vanilla formatter suite
This tool completes the site's zero-dependency formatter set. Use the JSON formatter for JavaScript objects, the JSON / YAML / TOML converter for switching between config formats, the SQL formatter for readable queries, and the URL encoder for the percent-encoded strings that appear inside XML attributes and CDATA payloads. All of them run in-browser with nothing uploaded — the same architecture as this page.
FAQ
Does the XML ever leave my browser?
No. Parsing runs entirely on the browser's built-in DOMParser and the serializer is plain JavaScript on this page. There is no upload endpoint, no server round-trip, and nothing is logged — which makes this safe to use with SOAP payloads that contain credentials, RSS feeds you have not published yet, or Android string.xml resources with unshipped copy.
What is "well-formed" XML, and what does the validator not check?
A document is well-formed if it follows the entry-level rules of XML: every element closed, tag names case-sensitive, attributes quoted, entities either predefined or declared, exactly one root element. This tool checks all of that. What it does NOT check is validity against a specific schema — DTD, XSD or RELAX NG — because that needs the schema file and is a separate stage. Well-formed but not valid means "the parser can read it" but "your business rules for what elements are allowed are not enforced."
Why does the output preserve <?xml version="1.0"?> when I paste it?
Because DOMParser silently strips the XML declaration on parse — it does not appear as a child of the document in the resulting DOM — so a naive round-trip would drop it. This tool detects the declaration in the raw input, holds it aside, parses the rest, and re-emits it at the top of the output. That is what most consumers expect, and what SOAP clients in particular tend to require.
How does the formatter handle mixed content like <p>Hello <em>world</em>!</p>?
Mixed content — text and elements interleaved inside the same parent — stays on a single line. If the formatter broke each child onto its own line, it would introduce whitespace that changes the rendered meaning of the text ("Hello world!" becoming "Hello\n world\n !"). The rule this tool follows: if any child of an element is a text node with content, that element is inlined; if every child is another element, they are broken across lines with indentation. It is the convention every well-behaved XML pretty-printer uses.