Skip to content
Back to Blog
By JSONConvert Team··6 min read

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 conceptJSON representationThe catch
Element with textstring valueLoses type info, everything arrives as a string
Attributekey with a prefix like @No standard prefix, converters differ
Repeated elementarrayA single element looks like an object instead
Nested elementnested objectClean, this part works
Namespace prefixkey with : or strippedEasy to lose meaning
Mixed contentspecial #text keyAwkward, often mangled
The two formats agree on nesting and not much else. Everything below is about handling the parts that do not agree.

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 true 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 ab 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.

Related Tools