XML Formatter and Validator
Format, minify and validate XML, and convert XML to JSON and back
Runs entirely in your browser. Nothing you type or upload is sent to us or stored.
Results are for general guidance. Please check anything important before relying on it. Terms of use
How to Use
- Choose what to do at the top: Format, Minify, Validate, XML → JSON or JSON → XML.
- Paste your XML (or JSON) into the input box, or tap Open an .xml or .json file. A sample order is loaded to start with.
- Set the options: indent of 2 spaces, 4 spaces or Tab; Remove comments when minifying; and the Attribute prefix in JSON for the conversions.
- The result updates as you type. If the XML isn't well-formed, the box turns red with the line, column and reason. Tap Show me to select that line in the input.
- Tap Copy or Download to save the result. After a conversion, Convert back sends the output the other way.
Format, check and convert XML in one place
XML still runs a lot of systems: Tally imports and exports, SOAP web services, Android layouts, Maven pom.xml files, RSS feeds, sitemaps and many bank and government data files. When it arrives on one long line, or a system rejects it with "invalid XML", this XML formatter and validator helps. It pretty-prints the file, tells you exactly where it's broken, minifies it, and converts between XML and JSON.
What formatting changes, and what it leaves alone
Formatting puts each element on its own line and indents children under their parent:
<invoice no="INV-42">
<party>
<name>Sharma Traders</name>
<gstin>27AAAPS1234A1Z5</gstin>
</party>
<!-- prices include GST -->
<amount>11800</amount>
</invoice>
Only the whitespace between tags changes. Comments, <![CDATA[ ]]> sections, the XML declaration, the DOCTYPE and every attribute are kept exactly as written. An element that mixes text and tags, like <p>Hello <b>there</b></p>, stays on one line, because adding line breaks inside it would change the text. Spaces at the start and end of a text-only element are trimmed, which is what most formatters do. If your system treats those spaces as data, keep the original.
What "well-formed" means
Validate checks the rules every XML file must follow (from the W3C XML 1.0 specification):
- Exactly one root element wraps everything else.
- Every opening tag has a matching closing tag, or is self-closing like
<br/>, and tags close in the reverse order they opened. - Tag names are case-sensitive:
<Name>can't be closed by</name>. - Attribute values are in quotes, and an attribute appears only once per element.
- A bare
&or<in text must be written as&or<, or placed inside CDATA.
A file can be well-formed and still be rejected by a particular system, because it doesn't match that system's schema (XSD), for example a missing required field. This tool doesn't check schemas.
XML to JSON and back
| XML | JSON (prefix @_) |
|---|---|
<city>Pune</city> | "city": "Pune" |
<item sku="A1">Tea</item> | "item": {"@_sku": "A1", "#text": "Tea"} |
Two or more <item> siblings | "item": [ ... ] (an array) |
<![CDATA[a < b]]> | "a < b" |
The attribute prefix keeps attributes apart from child elements; leave it empty to drop attributes. By default every value stays a string, because XML has no number type and a code like 007 or a PIN code should keep its digits. Switch on number detection only if you want 5 and true as JSON values.
Going from JSON to XML, a document must have a single root element, so JSON with several top-level keys, or a top-level array, is wrapped in <root>. Keys that aren't valid XML names, such as first name or 1st, are renamed to first_name and _1st, and the tool tells you when it does this. One thing doesn't survive a round trip: a single <item> becomes an object, not a one-item array.
Everything runs in your browser, so invoices, bank files and config with passwords are never uploaded.