XML Formatter
Beautify, validate and minify XML instantly. Pretty-print tangled markup with 2-space, 4-space or tab indentation, compact it back to a single line, and catch not-well-formed errors before they reach a parser. Attributes, text, CDATA, comments and processing instructions are all preserved. Everything runs in your browser with DOMParser; nothing is uploaded and no external entities are resolved.
Parsed locally with your browser's DOMParser — nothing is uploaded. No external entities (DTDs, SYSTEM references) are resolved and no network request is made, so pasting a document from an untrusted source cannot trigger an XXE fetch here. Safe for inspecting a SOAP envelope, SAML assertion or config file without sending it to a server.
What this tool is
- A free, in-browser XML formatter: beautify (pretty-print) tangled XML into clean, indented markup, or minify it back to a single line.
- Choose your indentation — 2 spaces, 4 spaces or a tab — and preserve attributes, text, CDATA sections, comments and processing instructions.
- Built-in validation: if the XML is not well-formed, you get a clear error message instead of broken output.
- Everything runs client-side using the browser’s native DOMParser. Your XML is never uploaded, and no external entities (DTDs or SYSTEM references) are fetched.
- Safe for sensitive payloads — SOAP envelopes, SAML assertions, config files, API responses — because nothing leaves your device and no XXE lookup is triggered.
What is XML?
XML (eXtensible Markup Language) is a text format for structured data built from nested elements wrapped in angle-bracket tags, each of which can carry attributes and contain text or further elements. It underpins a huge amount of infrastructure — SOAP web services, SAML single-sign-on assertions, RSS and Atom feeds, SVG graphics, Office documents (.docx, .xlsx), build files like Maven's pom.xml, and countless application configs. Because machine-generated XML is usually emitted as one dense line, a formatter is the quickest way to make it legible.
Well-formed vs. valid
These are two separate ideas. XML is well-formed when it follows XML's syntax rules: one root element, every tag closed and correctly nested, attribute values quoted, and the characters < and & escaped in text. XML is valid when it is also conformant to a schema (DTD, XSD or RELAX NG) that dictates the allowed elements, attributes and structure. This tool checks well-formedness — the thing you almost always want when formatting — and reports a clear error when the input does not parse. It does not validate against a schema, because that would require fetching the schema over the network, which this tool never does.
Pretty-print vs. minify
- Format (beautify). Re-indents the document so each nested element sits on its own line — ideal for reading, diffing and debugging. Pick 2 spaces, 4 spaces or a tab.
- Minify. Strips the formatting whitespace back out for the smallest valid representation — what you want for transport or storage. Significant text content is kept intact; only the insignificant whitespace between elements is removed.
Common errors it catches
Most "not well-formed" failures come from a handful of mistakes: an unclosed or mismatched tag, overlapping rather than nested tags, an unescaped & or bare < in text, a missing attribute quote, more than one root element, or stray characters before the XML declaration. When the parser rejects your input, the tool shows its error message so you can find the spot instead of guessing.
A note on XXE and billion-laughs
XML's biggest security footguns live in its document type definition. An XML External Entity (XXE) attack abuses an entity declaration such as <!ENTITY x SYSTEM "file:///etc/passwd"> — or one pointing at a remote URL — so that a parser configured to resolve external entities reads a local file or makes a server-side request the attacker controls, leaking data or enabling SSRF. The billion-laughs attack (an "XML bomb") instead nests entities that reference each other so that a few kilobytes expand into gigabytes in memory, a denial-of-service.
Why this tool is safe: it parses with the browser's native DOMParser, which does not resolve external entities and makes no network request to fetch a DTD or SYSTEM resource — so pasting a hostile document here cannot trigger an XXE file read or callout, and nothing you paste is ever uploaded. Running a well-formedness check in the browser is a sensible first pass before handing XML to a server-side parser, where you should disable DTD processing and external-entity resolution outright. A client-side formatter is not a substitute for hardening your back-end parser, but it is a safe place to inspect untrusted XML.
Frequently asked questions
What does an XML formatter do?
An XML formatter (also called an XML beautifier or pretty-printer) re-indents XML so its structure is easy to read: each nested element is placed on its own line and indented to show how deeply it is nested. Minified or machine-generated XML often arrives as one long line with no whitespace; the formatter parses it, rebuilds the element tree, and re-serializes it with consistent indentation. This tool lets you pick 2-space, 4-space or tab indentation, and it also goes the other way — the Minify button strips the formatting whitespace back out to produce the most compact valid representation for transport or storage.
What is the difference between well-formed and valid XML?
They are two different checks. XML is well-formed when it obeys the basic syntax rules of the XML specification: every start tag has a matching end tag, elements are properly nested, attribute values are quoted, there is a single root element, and special characters like < and & are escaped. XML is valid when, in addition to being well-formed, it conforms to a schema — a DTD, XSD or RELAX NG — that defines which elements and attributes are allowed and in what order. This tool checks well-formedness (the browser’s parser rejects malformed input), which is what the overwhelming majority of "format my XML" tasks need. It does not validate against an external schema, and deliberately so: fetching a schema would mean a network request, which this tool never makes.
What is the difference between pretty-print and minify?
Pretty-print (beautify) adds whitespace — newlines and indentation — to make the document human-readable, which is what you want when reading, diffing or debugging XML by hand. Minify removes all of that formatting whitespace to make the document as small as possible, which is what you want when sending XML over the wire or storing it, where every byte counts. Neither changes the actual data: the elements, attributes and text content are identical, only the insignificant whitespace between elements differs. Whitespace that is inside a text value (significant content) is preserved by both operations.
What are the most common XML errors?
The frequent causes of "not well-formed" errors are: a tag that is never closed or closed with the wrong name; overlapping instead of properly nested tags (for example <b><i>…</b></i>); an unescaped ampersand (& must be written as &) or a bare < inside text; a missing or mismatched quote around an attribute value; more than one root element; or a byte-order mark / stray characters before the XML declaration. When the input is malformed, this tool surfaces the browser parser’s own error message so you can locate the problem rather than guessing.
Is it safe to paste confidential XML here, and what about XXE?
Yes. All parsing and formatting happen entirely in your browser using the native DOMParser API — your XML is never transmitted to PlayCISO or anyone else. Just as importantly, this avoids the classic XML External Entity (XXE) risk: a malicious document can declare an external entity such as <!ENTITY x SYSTEM "file:///etc/passwd"> or point a DTD at a remote URL to exfiltrate data or trigger server-side requests. Browser DOMParser does not resolve external entities and makes no network request to fetch a DTD or SYSTEM resource, so pasting a hostile document here cannot cause that lookup. It also means this tool does not expand entities the way a server-side parser might — which is the safe default, and why running a quick well-formedness check in the browser is a sensible first step before ever handing XML to a back-end parser.