Why this specific conversion needs a real browser to run
Converting
For this specific example, repeated sibling
This array-for-repeated-siblings and @-prefix-for-attributes convention is a common, sensible approach to representing XML's richer structure (which JSON has no native equivalent for) in JSON form, but it's a convention this specific tool chose, not a universal XML-to-JSON standard every converter follows identically.
What XML has that JSON structurally doesn't
Repeated sibling tags become arrays. Attributes are prefixed with @. XML natively supports attributes on elements (like id="1" here) alongside element text content and child elements -- JSON has no equivalent concept, so any XML-to-JSON conversion has to make a design choice about how to represent that extra attribute data, which is why the @ prefix convention exists.
XML also natively supports mixed content (text interspersed with child elements within the same parent) and namespaces, both of which have no clean, universally-agreed JSON equivalent -- complex real-world XML with either of those characteristics may not convert as cleanly as this simple, well-structured example.
Because element order can matter in XML in ways it doesn't in a JSON object (whose key order isn't semantically meaningful in the JSON spec), some information about original element ordering can be lost or implicit in the JSON conversion for more complex documents.
Related structured-data conversion tools
For the reverse direction, or for other structured formats entirely, the JSON to YAML Converter and YAML to JSON Converter handle a different structured markup pair.
If the source XML represents a sitemap specifically, the XML Sitemap Validator checks that format's specific requirements instead of converting it.
Frequently Asked Questions (FAQ)
Why does this conversion require a browser rather than running as a simple script?
It uses the browser's native DOMParser to correctly parse the XML's nested-tag structure into a traversable document first, since XML's structure (attributes, nesting, repeated elements) is complex enough that a proper parser, not simple text pattern-matching, is needed to convert it reliably.
Why do the two <user> tags become a JSON array instead of two separate keys?
Repeated sibling tags become arrays. Attributes are prefixed with @. When multiple sibling elements share the same tag name under one parent, this converter groups them into a JSON array under that shared tag name, which is the standard way to represent XML's repeated-element pattern in JSON.
Why does the id attribute become @id in the JSON output?
JSON has no native concept of an element attribute distinct from its content. Prefixing attribute names with @ is a common convention for distinguishing them from the element's own text content or nested child elements in the resulting JSON structure.
Does this handle XML namespaces?
This tool is built for straightforward XML structures. XML namespaces add another layer of complexity (prefixed element names tied to namespace URIs) that doesn't have a simple, universal JSON equivalent, so heavily namespaced XML may not convert as cleanly as a simple document like this example.
Is the @-attribute-prefix convention a universal XML-to-JSON standard?
No, it's a common and sensible convention this tool uses, but not every XML-to-JSON converter represents attributes identically -- if you're matching output against another system's expected JSON shape, confirm that system uses the same attribute-prefix convention.
