XML to JSON: A Practical Conversion Guide
You asked an API for data and got back XML. Or you have a JSON config that a legacy system wants as XML. Either way, the two formats do not line up cleanly, and the naive "just convert it" step is where bugs sneak in. XML carries attributes, namespaces, and mixed content that JSON has no direct equivalent for, so every converter has to pick conventions. Knowing those conventions is the difference between clean output and a parsing headache.
Why XML and JSON Don't Map One-to-One
JSON has six types: object, array, string, number, boolean, and null. XML has elements, attributes, text nodes, namespaces, comments, and processing instructions, none of which carry a type. When you convert one to the other, the structures do not match, so something has to give.
Here is the core mismatch in one table:
| XML concept | JSON representation | The catch |
|---|---|---|
| Element with text | string value | Loses type info, everything arrives as a string |
| Attribute | key with a prefix like @ | No standard prefix, converters differ |
| Repeated element | array | A single element looks like an object instead |
| Nested element | nested object | Clean, this part works |
| Namespace prefix | key with : or stripped | Easy to lose meaning |
| Mixed content | special #text key | Awkward, often mangled |
The Attribute Problem
XML lets you put data in two places: as a child element or as an attribute. JSON only has keys and values, so a converter has to flatten attributes into the object somehow.
The common convention prefixes attributes with @ and keeps elements as plain keys:
Notice @active is the string "true", not a boolean. XML has no types, so active="true" and both arrive as strings. If you need a real boolean, cast it after conversion. Do not expect the converter to guess your intent.
The Repeated-Element Problem
This is the gotcha that breaks production code. XML has no array syntax. A list is just the same element repeated:
Converts to an array, as you would expect:
But what about an order with one item?
A naive converter produces an object, not an array:
Now code that calls order.item.map(...) throws, because item is a string this time. The shape of the JSON depends on how many elements the XML happened to contain. This is why XML-to-JSON output is risky to consume directly: normalize repeated elements to arrays, or check the type before you iterate.
Converting XML to JSON
For a typical conversion, paste the XML and read off the structure. Take this RSS-style snippet:
The XML to JSON converter turns it into:
Two elements became an array. Feed it a feed with one item and you get an object instead, which is the trap from the last section. After converting, run the result through the JSON formatter to pretty-print it and confirm the nesting is what you expected.
Converting JSON to XML
The reverse direction is more predictable because JSON is the stricter format. Every key becomes an element, and you decide whether any values should be attributes instead.
Becomes:
The JSON to XML converter handles the escaping you would otherwise forget: &, <, and > inside text become &, <, and >. Skip that step by hand and you produce XML that will not parse. One thing to decide up front: JSON arrays become repeated elements, so ["a", "b"] under a tags key becomes two elements, not a single wrapped list. If you need a shape, restructure the JSON before converting.
Namespaces and Mixed Content
Two XML features have no clean JSON home.
Namespaces use prefixes like . Most converters keep the prefix as part of the key ("soap:Envelope") or strip it entirely. Keeping it is safer, because stripping can collide two different Body elements from separate namespaces into one key and silently overwrite data.
Mixed content is text and elements together inside one element:
There is no good JSON shape for this. Converters usually invent a #text key and lose the ordering of the text relative to the element. If your XML has mixed content, like HTML embedded in a document, expect the round trip to be lossy. JSON was not built to represent it.
Round-Tripping Is Not Guaranteed
A common assumption is that you can go XML to JSON and back and get the original document. You usually cannot. Attribute order is lost, whitespace between elements is dropped, comments disappear, and the single-element-versus-array ambiguity means the converter has to guess on the way back. Treat the conversion as one-directional for the data you care about, not as a reversible transform of the whole document.
Before you convert in either direction, validate the input. Malformed XML or JSON produces confusing output rather than a clear error. Run JSON through the JSON validator first, and make sure your XML is well-formed (every tag closed, exactly one root element) before pasting it in. A five-second check saves you from debugging output that was wrong from the start.