XML Formatter — pretty-print, validate, minify
Paste any XML document and get it pretty-printed with consistent indentation, or stripped of whitespace for compact transmission. Native XML parser validates as you type.
Paste any XML document and get it pretty-printed with consistent indentation, or stripped of whitespace for compact transmission. Native XML parser validates as you type.
<?xml version="1.0" encoding="UTF-8"?>
<catalog>
<book id="1">
<title>Pride and Prejudice</title>
<author>Jane Austen</author>
<year>1813</year>
</book>
<book id="2">
<title>1984</title>
<author>George Orwell</author>
<year>1949</year>
</book>
</catalog>XML is older than JSON and still widely used in enterprise: SOAP web services, RSS/Atom feeds, OpenAPI YAML imports, Spring configuration, Microsoft Office documents (under the hood), Android resources, and countless legacy systems. Reading minified XML — like a 200KB SOAP response on one line — is essentially impossible without a formatter.
This tool runs the formatting purely client-side. Validation uses the browser's native DOMParser, which is the same XML parser that fetch() uses for application/xml responses. That means anything that fails here will fail in your code too — useful for debugging mismatched payload errors. Pretty-print with 2/4/8-space indent; minify back to a single line when you need to embed XML into JSON or a header value.
Yes. The <?xml version='1.0' ...?> declaration at the start is detected, kept verbatim, and placed on its own line in pretty output. The minified version also keeps it but on the same line as the root element.
Both are preserved. CDATA blocks pass through unchanged so the XML inside them stays escaped. <!-- comments --> are also kept as-is on their own line in pretty output.
Yes — SOAP is XML, so the same formatter works. Long Envelope/Body/Header structures become readable; deeply nested security headers indent correctly.
No, only well-formedness (matching tags, valid syntax). XSD schema validation requires the schema document itself and a more complex parser — out of scope for this tool. Use xmllint --schema or xmlstarlet for schema validation.
Yes. Formatting and validation happen entirely in your browser. Your XML — including any sensitive data inside it — never reaches our servers.
Where pretty-printing XML saves real time.
Enterprise SOAP responses are often returned as a single 100KB line. Pasting into the formatter makes the actual structure visible — what fault occurred, what fields were returned.
Most feed parsers minify their output. When debugging a feed integration, pretty-print to see how the server actually serialised <item> blocks vs how the spec describes them.
pom.xml and Spring application context files routinely run to thousands of lines. After a merge that breaks the indent, run them through the formatter to restore a consistent style before committing.
Strings.xml and other Android XML resources accumulate inconsistent indentation over time. Bulk-format them as a one-shot cleanup; commit the result; future diffs become readable.
Habits that keep XML pleasant to work with.
If your client code constructs XML by string concatenation, paste the result here before sending. Most missing-quote, mismatched-tag bugs become visible immediately. Also a good place to spot accidentally-injected user input.
XML files in source control read best with 2-space indent. Four-space gets unreadable in deeply-nested structures (Spring config, RSS with namespaces). Pick 2 and stick with it.
Some Windows tools save XML with a UTF-8 BOM at the start. The byte 0xEF 0xBB 0xBF before <?xml is technically allowed but breaks strict parsers. If validation fails on what looks like correct XML, check for and remove the BOM.
If you're choosing a serialisation format for new code, JSON is almost always the better default in 2026. XML still has its place (mature standards, tooling like XSLT, document-oriented use cases) but pays in verbosity and parser complexity for most app-to-app communication.