Convert XML to JSON with a stated convention for attributes, text, and repeated elements.
Start here Paste the XML document into the input box.
{
"order": {
"@id": "1042",
"@placed": "2026-08-15",
"customer": {
"name": "Ada Lovelace",
"email": "ada@example.com"
},
"items": {
"item": [
{
"@sku": "A-1",
"@qty": "2",
"#text": "Analytical engine"
},
{
"@sku": "B-7",
"@qty": "1",
"#text": "Punch card set"
}
]
},
"note": "Deliver before 5pm & ring the bell"
}
}Attributes become @name keys, text alongside elements becomes #text, and repeated sibling elements become an array.
Understand the format
There is no official mapping between XML and JSON, so every converter invents one. The useful question is not whether the output is correct but which convention it chose.
XML has attributes, elements, text, comments, processing instructions, namespaces, and ordering between sibling elements of different names. JSON has objects, arrays, strings, numbers, booleans, and null. There is no lossless way to express the first in the second, which is why no standard mapping exists and why two converters will disagree about the same document.
The most common losses are worth stating plainly. Comments and processing instructions disappear. The distinction between an attribute and a child element becomes a naming convention. Document order between elements of different names is not preserved by an object. And everything arrives as a string, because XML has no types of its own without a schema.
Attributes become keys prefixed with an at sign, so id="1" becomes "@id": "1". Text that sits alongside child elements becomes a "#text" key. An element with no attributes and no children collapses to its text, so <name>Ada</name> becomes "name": "Ada" rather than a nested object. This convention is close to the one popularised by the Badgerfish and xml2json conventions, and it is stated here so you can predict the output rather than discover it.
Repeated sibling elements become an array. That produces the classic trap: <items><item/></items> with one child yields an object, and with two yields an array. Consumers that index the result blindly break the moment a document arrives with a single item. If you control both ends, declare which elements are always collections and normalise them before consuming.
Converting is a good idea when you are reading a document by hand, exploring an unfamiliar feed, or moving data into a system that speaks JSON natively. It is a bad idea as a compatibility layer in a pipeline you control: you inherit the ambiguity above, and every consumer has to know the convention.
Where a schema exists, generating typed objects from the XSD is almost always better than converting to JSON and inferring types at runtime. The conversion here is for reading and prototyping, not as a replacement for a contract.
Step by step
The document is parsed and converted in your browser. Nothing is transmitted, which matters for supplier feeds and configuration files that often carry credentials.
Worked examples
Input
<item sku="A-1" qty="2">Widget</item>
Result
{
"item": {
"@sku": "A-1",
"@qty": "2",
"#text": "Widget"
}
}Attributes are prefixed, and the element text needs its own key because the object is already holding the attributes.
Input
<items><item>A</item></items> versus two items
Result
"item": "A" versus "item": ["A", "B"]
The shape of the output depends on the data, not on the schema. This is the single biggest source of bugs when consuming converted XML.
Reference
| XML | JSON | Note |
|---|---|---|
| <a>text</a> | "a": "text" | Collapses when there are no attributes or children. |
| <a id="1"/> | "a": { "@id": "1" } | Attributes are prefixed with @. |
| <a id="1">t</a> | "a": { "@id": "1", "#text": "t" } | Text needs its own key. |
| Repeated <b/> siblings | "b": [ ... ] | One occurrence stays an object. |
| <![CDATA[raw]]> | Part of the text value | The CDATA wrapper itself is not represented. |
| Comments | Dropped | JSON has no comment syntax. |
| Namespaces | Kept in the key, as ns:name | Prefixes survive; their URI bindings do not. |
| Everything | Strings | XML has no types without a schema, so "2" stays a string. |
Practical Guide
Troubleshooting
FAQ
No. The formats model different things, so every library invents a convention. The one used here is stated on this page precisely because you cannot assume it matches another tool.
Because an object key cannot distinguish an attribute from a child element on its own. The prefix keeps both in one object without collisions, which is the convention most converters follow.
Because the converter sees one occurrence and cannot know the schema allows more. This is the ambiguity at the heart of the mapping, and it is why consumers should normalise collections.
A prefixed name such as ns:item is kept as the key. The binding between the prefix and its URI, declared by xmlns, becomes an ordinary attribute and loses its special meaning.
Not currently. The reverse direction has to invent element names and decide what becomes an attribute, so it needs its own set of stated choices.
No. Parsing and conversion both run in the page, so nothing leaves your browser.
Go deeper