XML Formatter & Validator
Format, minify, and validate XML in your browser. Pretty-print and catch errors.
XML to JSON Converter
Convert XML into JSON or JSON into XML in either direction. Attributes are preserved with an <code>@</code> prefix, repeated elements collapse into arrays, text content stays inline. Useful when you're consuming a SOAP API and want to work with JSON in your code, or shipping JSON data to a system that only accepts XML. The conversion is lossless for typical real-world payloads.
How to Use This Tool
- Paste your input into the left panel — XML or JSON, the tool detects which.
- Click XML to JSON or JSON to XML depending on which direction you want. The output appears in the right panel.
- Read the status bar below — it confirms a successful conversion or shows the parse error if the input was malformed.
- Copy the output with the Copy button, or paste into the left panel and convert the other direction to round-trip.
How XML and JSON Differ
XML and JSON solve the same problem — encoding structured data as text — but they were designed at different times for different audiences. JSON came out of the late-1990s JavaScript world: minimal syntax, types built into the format (string, number, boolean, null, array, object), no schema, easy to consume in browsers. XML came out of the late-1990s document world: tags can carry both attributes and content, types are everything-is-a-string by default, schemas (DTD/XSD) are first-class. Most modern web APIs picked JSON because it maps cleanly to objects in every language; most enterprise integration formats picked XML because it can carry document semantics that JSON can't.
Converting between the two is mostly mechanical, with a few decisions baked into any conversion library: how to represent attributes (this tool uses the @ prefix), how to handle repeated child elements (collapse into JSON arrays), how to handle mixed text-and-elements content (use the #text key for text alongside attributes), and how to handle namespaces (preserve the prefix verbatim). The conventions used here match what xmltodict (Python), xml-js (Node.js), and similar libraries do — so the JSON output here will round-trip correctly through any of those tools.
The conversion is lossless for typical structured-data XML: SOAP responses, RSS items, configuration files, exported records. It loses information for document-style XML where text and elements freely interleave (XHTML, formatted prose), because JSON has no clean way to represent the order of mixed content. If your XML looks more like a document than a data record, keep it as XML; if it looks like a row of database fields with attributes, JSON conversion is straightforward and the result is easier to consume.
Frequently Asked Questions
How are XML attributes represented in the JSON output?
Attributes are prefixed with
@ in the JSON keys, so <book id="1"> becomes {"book": {"@id": "1"}}. This convention (popularized by the BadgerFish format) is unambiguous, easy to round-trip back to XML, and widely supported by XML-to-JSON libraries in other languages including Python's xmltodict, JavaScript's xml-js, and PHP's array conversion. When converting JSON back to XML, any key starting with @ is emitted as an attribute on the parent element.What happens when an element appears more than once at the same level?
Repeated child elements with the same tag name collapse into a JSON array. So
<list><item>A</item><item>B</item></list> becomes {"list": {"item": ["A", "B"]}}. A single occurrence stays a non-array value, so <list><item>A</item></list> becomes {"list": {"item": "A"}}. This is the standard XML-to-JSON convention and matches what xmltodict, xml-js, and most other libraries do — but it does mean a downstream JSON consumer needs to handle either shape, since the same XML schema can yield either.Can I round-trip XML to JSON and back without losing data?
For typical structured data — elements with attributes, text content, and nested children — yes, the conversion is lossless and round-trips cleanly. The cases where information is lost: comments are stripped, processing instructions are stripped, the order of differently-named sibling elements is preserved but not the order of mixed content, and namespace prefixes survive but the original xmlns binding may need to be re-added by hand. For document-style XML with significant mixed content (text and elements interleaved within one parent), JSON is the wrong target format and you should keep it as XML.
How is text content represented when an element has both text and attributes?
When an element has attributes, the text content goes into a
#text key alongside the @-prefixed attributes: <name lang="en">Janeer</name> becomes {"name": {"@lang": "en", "#text": "Janeer"}}. When an element has no attributes and only text, the text is the value directly: <name>Janeer</name> becomes {"name": "Janeer"}. This keeps simple cases simple and only adds nesting when needed.When should I convert XML to JSON in the first place?
Convert when the destination system speaks JSON natively and the source is locked to XML — typical examples include SOAP-to-REST gateways, legacy ERP/CRM data going into modern JavaScript frontends, or RSS feed processing. Don't convert if either side handles both formats, if the XML uses heavy mixed content (XML is genuinely better at that), or if you're building a system from scratch (just pick one format and stay with it). The conversion is a useful bridge between systems that disagree, not a transformation you should do for stylistic reasons.