How XML maps to JSON: attributes, arrays and types

XML to JSON conversion looks trivial until the first real document arrives with attributes, repeated tags and values that are numbers in spirit but text on the wire. The conversion follows a small set of rules. Once you can see them, the output stops being surprising. This piece walks through those rules so you know what to expect before you paste anything into a converter.

Rule 1: elements become objects, text becomes values

A leaf element with only text collapses to that text value. An element with child elements becomes an object whose keys are the child tag names. This is the part everyone expects, and for plain trees it is all you need. The interesting behaviour starts when an element carries more than just nested elements.

Rule 2: attributes become @-prefixed keys

XML attributes have no direct equivalent in JSON, so the widely used convention is to prefix them with @. An element like <price currency="USD">39.95</price> converts to an object with an @currency key for the attribute and a #text key for the value. Keeping them separate matters: flattening the attribute and the text into one value would lose information. In finance or healthcare data that lost attribute can change meaning. Our XML to JSON converter lets you toggle attribute handling so you can drop them when a consumer only wants element values.

Rule 3: repeated tags become arrays

This is the rule that causes the most production bugs. A tag becomes a JSON array only when it appears more than once under the same parent. So a catalog with three <product> tags produces an array of three, but a catalog with one <product> produces a single object—not an array of one. Code that assumes an array will break the day a feed happens to contain exactly one item. The fix is to normalise logically-repeating fields to arrays in your consumer rather than trusting the document to always have two or more.

Rule 4: mind the type fidelity gap

XML is stringly-typed. A number, a boolean and a date all look identical inside a tag—they are just text. JSON, by contrast, distinguishes numbers, booleans and null natively. A good converter coerces values that are unambiguously numeric or true/false into real JSON types, but it should deliberately leave anything with leading zeros, plus signs or thousands separators as a string, because 00713 is almost always an identifier rather than the integer seven hundred and thirteen. When your downstream contract is strict, cast explicitly in the consumer and capture the expected types with the JSON Schema generator so a future feed change shows up in review.

The rules in one table

Putting the rules together

Take this fragment:

<order id="A-100">
  <item sku="KB-1">Keyboard</item>
  <item sku="MS-2">Mouse</item>
  <total currency="USD">61.00</total>
</order>

It converts to an object with an @id attribute key, an item array of two objects (each with @sku and #text) and a total object carrying @currency and a numeric #text. Every rule above is visible in that one example: attributes prefixed, repeated tags arrayed, text preserved under #text and the total coerced to a number.

Where this fits in the series

This mapping is the engine behind the whole topic. For the bigger picture of when to use each format, see XML vs JSON: the practical differences. For the two most common sources of XML you will actually convert, read turning SOAP XML into JSON and reading RSS and Atom feeds as JSON.

Frequently asked questions

How are XML attributes represented in JSON?
They are prefixed with @ on the element object, which keeps attributes distinct from element content rather than flattening them together.

Why does a single-item list look different from a multi-item list?
A tag becomes an array only when it repeats under the same parent. Normalise logically-repeating fields to arrays in your consumer so the one-item case does not break.

Bottom line

XML to JSON conversion is predictable once you hold four rules in your head: elements become objects, attributes become @ keys, repeated tags become arrays and types need confirming because XML has none. Keep those in mind, validate the result with the JSON validator and the awkward documents stop being a mystery.