Pretty-print messy XML with proper indentation, validate it with clear error messages, minify it for production, or convert it straight to JSON — all processed locally in your browser.
JSON won the web API war, but XML never left the building. SOAP services still run banking, insurance, and government integrations; every RSS feed, sitemap, and SVG file is XML; Android layouts, Maven's pom.xml, .NET project files, and Microsoft Office documents (a .docx is zipped XML) all speak it daily. When one of these lands in your editor as a single unreadable line — which is how systems typically emit it — you need exactly three operations: format it to see the structure, validate it to find what's broken, and often convert it to JSON to use in modern tooling. This page does all three.
XML is stricter than HTML: every tag must close, tags must nest properly (<a><b></a></b> is fatal), attribute values must be quoted, and the five special characters (& < > " ') must be escaped as entities inside content. The single most common real-world error is a bare ampersand — a URL like ?a=1&b=2 pasted into an XML value breaks the document unless written as &. The validator here uses your browser's native XML parser, the same engine that renders SVG and feeds, and reports the line where parsing failed. Note the distinction: this checks well-formedness (syntax); whether the document matches a specific schema (XSD) is a separate, stricter question that requires the schema file itself.
XML and JSON model data differently — XML has attributes, JSON doesn't; XML distinguishes child order, JSON objects don't — so any conversion picks conventions. This tool uses the widely adopted ones: attributes become keys prefixed with @, element text becomes the value directly (or a #text key when an element has both text and attributes), and repeated sibling elements collapse into a JSON array. So <item sku="A1" qty="2"/> becomes {"@sku": "A1", "@qty": "2"}, and three <item> siblings become an item array. The result drops into JavaScript, Python, or our JSON Formatter and JSON to CSV tools without ceremony. One caveat worth knowing: comments, processing instructions, and CDATA markers don't survive — JSON has no equivalent for them.
No — parsing, formatting, and conversion all run on your browser's built-in DOM parser. Enterprise payloads and config files stay on your machine.
If the whole document is on one line, every error is "on line 1". Format what parses, or check the classic culprits in order: unescaped &, an unclosed tag, mismatched nesting, or a stray character before the <?xml?> declaration (often an invisible BOM).
Formatting changes only whitespace between elements. One nuance inherited from the XML spec: whitespace inside mixed text content is significant, and the formatter preserves it — so text values are never altered.
Not here — JSON-to-XML needs decisions this tool can't guess (root element name, attribute vs element for each key, array item naming). The XML → JSON direction covers the common workflow: consuming legacy XML in modern JSON-first code.
No — browsers don't expose XSD validation. This tool guarantees well-formedness; schema conformance needs a tool that loads your XSD, like xmllint --schema or your IDE.
Multi-megabyte documents format fine; very large files (tens of MB) may take a few seconds since the whole tree is parsed in memory.
Yes — namespace declarations and prefixed element names (<soap:Envelope>) survive formatting and minification intact, since they're structurally just attributes and qualified names. In the JSON conversion, prefixed names become keys as-is ("soap:Envelope").
The formatter normalizes representation without changing meaning: empty elements become self-closing (<item/>), attribute values get double quotes, and inter-element whitespace is rebuilt. A round-trip through any standards-compliant parser produces the same document either way.