Why attributes get an @ prefix#
XML has two fundamentally different ways to attach data to an element — child elements and attributes — while JSON has only one, a plain object key. Without some convention to tell them apart, <book id="1"><title>X</title></book> and <book><id>1</id><title>X</title></book> would produce identical, ambiguous JSON, losing the distinction entirely. Prefixing attribute keys with @ (the convention used by most XML-to-JSON libraries, including this tool) keeps that distinction visible in the output, so nothing about the original document's shape is silently lost in translation.
The bug this tool avoids: silently losing repeated elements#
A naive attribute-by-attribute converter that just assigns each child to an object key will silently overwrite earlier entries when the same tag name repeats — three <book> elements inside a <catalog> become one, with the first two discarded, unless the converter specifically detects the repetition and switches that key to an array. This tool tracks that automatically: the first <book> becomes a plain object under the book key, and the moment a second one appears, the key becomes an array holding both — this is the single most common correctness bug in hand-rolled XML-to-JSON code, and the exact reason this tool reuses the site's own tested XML tokenizer rather than a second, less careful implementation.
What doesn't survive the conversion#
Comments, processing instructions, the DOCTYPE declaration, and the leading <?xml version="1.0"?> declaration have no JSON equivalent and are dropped entirely — JSON has no concept of a comment or a document-type declaration. If any of that metadata matters for your use case, it needs to be preserved separately; this conversion is strictly about the data the XML actually structures.