Why do some keys start with an @?

Those were XML attributes rather than child elements. JSON has no equivalent distinction, so the prefix preserves it. It is the convention most XML-to-JSON tooling uses.

Why is a single element not an array?

Because XML gives no indication that an element can repeat — that lives in the schema, not the document. One occurrence looks like a single value and several look like a list, which is a real trap when writing code against the result.

What happens to namespaces?

The prefix is kept as part of the key. JSON has no namespace concept, so the meaning behind the prefix is lost even though the text of it survives.

Where did my comments and processing instructions go?

They are dropped. Neither has any representation in JSON, and carrying them would require inventing a convention that nothing else would understand.

XML to JSON

Parse XML into JSON, with attributes preserved.

Everything runs inside your browser. Your files never leave your device.

Input

Result

The result appears here as you type.

Ask about XML to JSON

Questions about what this tool does, which option to pick, or what it can and cannot handle.

The question you type here is sent to an AI provider to be answered — your files and whatever you put in the tool above are not, and the assistant cannot see them. Answers are generated and can be wrong. The tool itself is not guessing: it runs deterministic code on your device.

About the XML to JSON

XML and JSON describe the same kind of nested data with entirely different assumptions, which is why converting between them requires decisions rather than just a parser. This converts XML into JSON and states the decisions it is making.

The core difficulty is that XML distinguishes between an attribute and a child element while JSON has only keys. An element with attributes and text content has to become an object with a convention for both, and the usual approach — which this follows — prefixes attribute names with an @ symbol and puts text content under a dedicated key. That is the convention most XML-to-JSON tooling has settled on.

The second difficulty is repeated elements. A parent with three child elements of the same name should become an array; a parent with one should arguably become an object, except that then the shape of the JSON depends on the data rather than the schema, and code that worked yesterday breaks when a list happens to have one item. That is a genuine trap, and it is worth deciding deliberately which behaviour you want rather than discovering it in production.

Namespaces are the third. XML namespaces carry meaning that JSON has no way to express, so a prefixed element name either keeps its prefix as part of the key or loses the distinction entirely. Neither is a faithful translation because there is no faithful translation available.

The practical use for this is reading, more than converting: an XML response is much easier to scan as JSON, and pasting one in here is often the fastest way to work out what a SOAP endpoint or an RSS feed is actually returning. For production parsing, an XML library that understands namespaces will serve you better than a conversion.

How to use it

1Paste the XML document or fragment.
2Read the JSON output — attributes appear with an @ prefix and text content under its own key.
3Look carefully at any element that can repeat, since one occurrence and several produce different shapes.
4For production code, parse the XML with a real library rather than converting first.

Questions

Why do some keys start with an @?: Those were XML attributes rather than child elements. JSON has no equivalent distinction, so the prefix preserves it. It is the convention most XML-to-JSON tooling uses.
Why is a single element not an array?: Because XML gives no indication that an element can repeat — that lives in the schema, not the document. One occurrence looks like a single value and several look like a list, which is a real trap when writing code against the result.
What happens to namespaces?: The prefix is kept as part of the key. JSON has no namespace concept, so the meaning behind the prefix is lost even though the text of it survives.
Where did my comments and processing instructions go?: They are dropped. Neither has any representation in JSON, and carrying them would require inventing a convention that nothing else would understand.