Convert XML documents into JSON in your browser. Keep attributes under @-prefixed keys, collapse repeated elements into arrays and optionally coerce numbers, booleans and null.
Read XML as the object tree it always wanted to be. Paste an XML document and get JSON back. Attributes are preserved under @-prefixed keys, repeated elements collapse into arrays, and type coercion is opt-in so identifiers keep their leading zeros.
XML draws a firm line between attributes and child elements. <user id="7"><name>Ada</name></user> says something different from <user><id>7</id><name>Ada</name></user>, even though most applications treat them identically. JSON has no equivalent distinction, so a converter must either throw attributes away or invent a place for them.
The widely used convention, and the one applied here, prefixes attribute keys with @ and stores element text under #text when an element has both attributes and content. So the first example becomes {"user": {"@id": "7", "name": "Ada"}}. The prefix is not part of any standard, but it is common enough that most downstream code recognises it, and it keeps the conversion reversible. Turning attributes off produces cleaner output when you know the attributes are metadata you do not need.
This is the problem with no correct answer. In XML, a parent with a single <item> child and a parent with five look structurally similar, but they must become a single object and an array respectively — and nothing in the document tells you which the schema intended. A tool without a schema has to guess from what it sees.
The rule here is to collapse repeated sibling element names into an array and leave a lone element as a single value. That matches intuition when reading, but it means code consuming the output must handle both shapes, because a list that happens to have one entry today will produce an object rather than a one-element array. When you control the consumer, normalise with something like [].concat(value) before iterating.
There are no types in an XML document without a schema. <count>42</count> and <sku>0042</sku> are both just text, and only a human or an XSD knows that one is a number and the other is an identifier that must keep its zeros.
That is why type coercion is a checkbox rather than the default. When it is on, values are converted only when the round trip is exact — a numeric string becomes a number only if formatting it back produces the identical text, which protects 0042, +7 and 1e999. true, false and empty elements become booleans and null. When it is off, every value stays a string, which is the safer choice for identifiers, phone numbers, postcodes and any integer beyond 2^53 where JavaScript number precision would silently corrupt the value.