Converting XML to JSON: what actually changes

XML and JSON both represent structured data, but they don't map onto each other one-to-one. XML has concepts JSON simply doesn't — attributes, mixed content, namespaces, a distinction between an element with one child and an element with a list of children that happens to have one item. Converting between them means making decisions about how to flatten those concepts, and different converters make different decisions.

The attribute problem

XML elements can carry both attributes and a text value at once: <price currency="USD">19.99</price>. JSON objects don't have an "attribute" concept — everything is just a key. Most converters solve this with a prefix convention, turning the above into something like {"price": {"_currency": "USD", "_text": "19.99"}}. That's reasonable, but it means the JSON shape depends on whether the source XML happened to use attributes or child elements for the same piece of data — worth checking against a sample before you write code that consumes the output.

The single-item array problem

This is the one that breaks the most real code. If an XML element can legally repeat — <items><item>...</item></items></code>— a converter typically has to guess, from a single document, whether item should become a JSON array or a bare object. With two <item> elements in the sample, you get an array. With exactly one, some converters produce a bare object instead of a one-element array, and code written against "items is always an array" throws on that input. When repetition is possible in your schema, check the converted output against both a single-item and a multi-item example before shipping.

Namespaces get ugly fast

XML namespaces (xmlns:foo="...") exist to avoid tag-name collisions across combined documents. JSON has no equivalent, so namespaced tags usually survive conversion as literal prefixed keys like "foo:bar", which is valid JSON but awkward to consume — most JSON tooling assumes keys are plain identifiers, not colon-delimited namespace pairs.

When XML-to-JSON is the right move

• Feeding a JavaScript/JSON-native pipeline — most frontend and Node.js tooling consumes JSON far more naturally than XML.
• Quick inspection — JSON is usually easier to skim than deeply nested XML, especially with a formatter.
• API migration — bridging a legacy XML API response into a JSON-based service layer.

If you're validating structure rather than converting it, an XPath tester or XML validator might be the better first stop — converting first can hide the exact issue you're trying to find.

Our XML to JSON converter runs the conversion locally in your browser — useful for spot-checking exactly how your specific document's attributes and repeated elements come out before you build a pipeline around the assumption.