XML to JSON Converter

Why This Conversion Needs a Convention

XML to JSON is not a symmetric operation, and understanding why saves a lot of confusion. XML has four distinct kinds of node content: attributes, text, child elements, and comments. JSON has exactly two things: keys and values. Four into two does not go, so every converter invents a convention to encode the extra distinctions.

The most widely used convention prefixes attribute names with an @ sign and stores an element's own text under a key such as #text. Both characters are chosen precisely because they cannot appear at the start of an XML element name, so there is no risk of a collision with a real child.

Side by Side Example

An RSS style feed fragment showing attributes, repeated elements, and mixed content in one document.

Look closely at the two tag values. The first item has an array because it had two tag children. The second has a bare string because it had one. Identical structure in the source produces different types in the output, and that is the single biggest hazard of this conversion.

The Single Element Ambiguity

Nothing in an XML document says whether an element is repeatable. Repeatability lives in the schema, and most documents arrive without one. A converter can only look at what is present, so one occurrence looks like a scalar and two look like a list.

Downstream code then breaks in a way that passes every test on the sample file and fails in production the first time a customer sends a document with only one item. There are three practical defences.

1. Configure a forced array list, naming the elements that are always arrays regardless of how many occurrences appear. This is the correct fix when you know the schema.
2. Force every repeatable looking element to an array unconditionally, which produces uglier JSON but is completely predictable.
3. Normalise defensively in the consuming code, wrapping any non array value in a one element array before iterating.

Mapping Conventions Reference

Whitespace and Mixed Content

Pretty printed XML is full of whitespace text nodes: the newline and indentation between a parent tag and its first child are, strictly speaking, text content. Converters trim them, which is almost always what you want and is technically lossy for elements where whitespace is significant.

Mixed content is the genuinely awkward case. Document oriented XML lets text and elements interleave freely, and JSON has no way to express interleaving order.

If your XML is document oriented rather than data oriented, JSON may be the wrong target entirely. Keep the markup as a string and parse it with an HTML or XML aware renderer instead.

Namespaces and CDATA

Namespaces exist so that two vocabularies can be mixed in one document without their element names colliding. A prefix such as dc: is bound to a URI by an xmlns declaration, and the prefix itself is arbitrary: what identifies the element is the URI it resolves to.

JSON has no namespace mechanism, so converters typically flatten. Either the prefix is kept as part of the key, giving dc:creator as a literal key name, or it is stripped entirely, giving creator. Stripping is tidier and risks collisions if two namespaces use the same local name. The xmlns declarations themselves usually survive as ordinary attributes, so you may see @xmlns:dc in the output.

CDATA sections are simpler than they look. A CDATA block is just a way of writing text that contains angle brackets and ampersands without escaping each one, commonly used for embedded HTML or scripts. It carries no meaning of its own, so in JSON it becomes an ordinary string and the wrapper disappears. If the original CDATA held markup, that markup is now a string inside your JSON and still needs escaping before you insert it into a page.