XML to JSON: What Gets Lost and How to Convert Faithfully

The structural mismatch

In XML an element carries data in three ways: as a child element, as an attribute on the tag, and as text content. JSON has no equivalent of attributes and no separate text-vs-element distinction - an object just has named values. So conversion invents a convention: attributes are typically promoted to keys (often prefixed, like @attr) and text is mapped to a special key like #text when an element has both text and children.

None of these conventions is universal. The same XML can be converted to JSON in several legitimate ways, so an output is only meaningful together with the rules that produced it - never assume your parser maps things the way the sender's did.

The one-vs-many problem (the big silent break)

XML has no arrays: a repeating node is expressed as multiple sibling elements, and you cannot tell from a single instance whether it is "one item" or "a list of one." Converters usually make repeated elements into JSON arrays and a lone element into a single object - which means the shape changes based on count. A consumer expecting items to always be an array breaks the day it receives one item that arrives as an object.

This is the most damaging loss in XML-to-JSON work precisely because it hides until an edge case appears. The robust fix is to know the schema and force a consistent array for known-repeating elements, or use a converter whose behaviour you can verify against multi- and single-item samples.

The converter here preserves attributes and handles CDATA as text, but the array-vs-object decision still depends on how many copies appear - always check the single-item case.

Mixed content, whitespace and CDATA

XML lets text and elements interleave inside one node (mixed content), which has no clean JSON home - flattening it discards where each piece sat. Whitespace-only text nodes can appear as stray keys unless trimmed. CDATA sections are raw character data (often embedded markup or code); the sensible handling is to expose them as ordinary string values, which is what this tool does.

Namespaces add another wrinkle: <xs:element> - do you keep the prefix, drop it, or expand the URI? Different tools differ, and dropping prefixes can collide two distinct elements into one key.

When you should not convert at all

JSON is friendlier for APIs and storage, but some XML has no good JSON twin. If you rely on document order across mixed element types, on XML schema/namespace validation, on XSLT transforms, or on SOAP, converting to JSON discards the very features you need. Keep XML where XML is load-bearing; convert when you genuinely just want the data tree.

After conversion, verify the JSON before trusting it: run it through the JSON validator and formatter, and to go back use the JSON to XML converter - remembering that a JSON round-trip is not guaranteed identical because of the conventions chosen on the way out.