XML to JSON Converter
There is no standard mapping between XML and JSON, which is why two converters can produce different output from the same input and both be defensible. XML carries attributes, namespaces, ordering, and mixed content; JSON carries none of those. This page converts both directions and is explicit about the choices it makes.
How to use it
- Select XML to JSON or JSON to XML.
- Drop in your .xml or .json file. Parsing is local to the page.
- Download the result.
How attributes and elements are distinguished
XML lets the same information live in two places. Both of these are ordinary XML, and they mean roughly the same thing to a human reader, but they have different shapes.
An attribute-carrying element such as <user id="7">Ada</user> has to become something in JSON that separates the attribute from the text content. The converter prefixes attribute names so they cannot collide with child element names, and puts the element text under a dedicated key. Without that separation, an element with both an id attribute and an id child element would silently overwrite one with the other.
The single-element array problem
This is the failure mode that breaks production code most often. In XML, a list of one item and a single item are written identically. A parser reading <items><item>A</item></items> cannot tell whether item is meant to be a collection with one entry or a lone value, because the XML itself does not say.
The practical consequence is that the same code path produces an object when the source data happens to contain one record and an array when it contains two. Any consumer that assumes an array will crash on the single-record case, typically in production, typically on a quiet day when volume is low. If you control the consuming code, normalise the field to an array before using it rather than trusting the shape.
Namespaces, mixed content, and CDATA
Namespace prefixes are preserved as part of the key name, so soap:Envelope stays distinguishable from Envelope. The namespace URI declarations themselves appear as ordinary attributes, because JSON has no concept of a namespace scope.
Mixed content, meaning an element containing both text and child elements, is the case where the mapping is genuinely lossy. XML preserves the interleaved order of text and children; JSON objects do not preserve that relationship at all. Documents that are prose with inline markup, such as XHTML fragments, do not survive this conversion in a usable form.
CDATA sections are unwrapped, and their contents become ordinary string values. The escaping distinction disappears, which is normally what you want, since JSON has its own escaping rules.
At a glance
| Accepted input | .xml, .json |
|---|---|
| Attributes | Prefixed to avoid collision with child elements |
| Namespaces | Prefix retained in key name |
| Mixed content | Lossy, ordering not preserved |
Frequently asked questions
Why is one record an object but two records an array?
Because XML does not distinguish a one-item list from a single item. No parser can infer the difference without a schema. Normalise the field in your consuming code, or supply an XSD-aware tool if you need the distinction enforced.
Can it handle a SOAP envelope?
Yes, structurally. Namespace prefixes are kept in the key names, so soap:Body remains distinct. Whether the resulting JSON is convenient depends on how deeply the envelope nests.
Will the XML I generate from JSON validate against my original schema?
Probably not without adjustment. Going JSON to XML has to invent decisions about what becomes an attribute and what becomes an element, and a schema usually has opinions about that. Treat the output as a starting point.
What happens to XML comments and processing instructions?
They are dropped. Neither has a JSON representation, and both sit outside the element data model that the conversion targets.
Read more
CSV, JSON, YAML, XML: choosing a data format — Every conversion between these formats loses something. Knowing what, in advance, prevents most of the resulting bugs.