XML to JSON without guessing the shape

As ordinary object keys with a marker that keeps them apart from child elements — @id by default here, with @_id, $id, no prefix at all, or dropping them entirely as the alternatives. The marker exists because JSON has one kind of member and XML has two: without it, an attribute called price and a child element called price collide into one key and one of them is lost. This page counts those collisions and names the paths where they happen rather than silently keeping the last one.

Because arrays in this mapping come from repetition, and a record with one child has nothing to repeat. A <tags> element holding two <tag> children produces an array; the next record with a single <tag> produces a string, and any code doing data.tags.tag.map() crashes on the second record. The document itself cannot resolve this — nothing in a well-formed XML file says an element is a list — so either switch to “Always an array”, or read the schema, where maxOccurs tells you what the author intended.

Prefixes are kept as part of the key by default, so <dc:creator> becomes "dc:creator", and the xmlns declarations arrive as ordinary attributes because that is what they are. Stripping prefixes gives you "creator", which is friendlier to consume and loses the only thing distinguishing two identically named elements from different vocabularies — an Atom feed mixing atom:title with a custom title is the usual casualty. The namespace URI itself has nowhere to go in either mode.

The text inside survives; the wrapper does not. <![CDATA[<b>hi</b>]]> and &lt;b&gt;hi&lt;/b&gt; are two spellings of the same characters in XML, and both arrive as the JSON string "<b>hi</b>" — nothing marks which spelling the source used. That matters when you convert back, because a value that was hand-written as CDATA to keep it readable will return as an escaped string.

The text is gathered into the text key and the children become members, which loses the order between them. <p>Call <b>now</b> before Friday</p> is a sentence in XML and becomes {"b": "now", "#text": "Call before Friday"} in JSON — the words survive, their positions around the <b> do not. Mixed content is counted in the report because prose-shaped XML is the one case where converting to JSON destroys meaning rather than reshaping it.

Because <coupon/> and <coupon></coupon> are the same thing in XML and neither says whether the value is absent or blank. null is the reading most converters take and the one this page takes; if your producer means an empty string, it should be sending one explicitly. The count of empty elements appears in the report so you can see how many nulls came from this rule rather than from real data.

No — there is no W3C or IETF specification for it, only conventions, which is why two converters disagree about your file. The named ones are Parker (drop attributes, keep the text), BadgerFish (attributes prefixed with @, text under $), JsonML (arrays that preserve document order) and the defaults in libraries like fast-xml-parser and xml-js. This page implements the widely used attribute-prefix convention with the choices exposed, because picking one silently is what makes converter output non-portable.