XML to JSON Converter

The one thing that will break your code

This is the fundamental problem with converting XML to JSON, it catches almost everyone once, and no other converter page mentions it.

XML has no way to say "this is a list". A list containing one order and a single order look exactly the same in the file — there is no syntax that distinguishes them.

So when an element appears once, it becomes an object. When it appears twice or more, it becomes an array. The shape of your JSON depends on your data, not on your schema.

The consequence is a bug that appears later and looks mysterious. You convert a sample file with one order in it, write code that reads data.orders.order.id, ship it, and it works. Then a file arrives with two orders, order is suddenly an array, and .id is undefined. Nothing changed in your code and nothing was wrong with the conversion.

Two defences, and it is worth applying both. Test with a file that has multiple items — and with one that has zero, where the element may be missing entirely. And normalise as you read: wrap anything that could repeat, so a single value becomes a one-item array before you use it. In JavaScript that is const list = [].concat(data.orders.order ?? []), and every language has an equivalent. One line, and the class of bug disappears.

Attributes have to go somewhere

XML carries information in two places — inside elements and in attributes — and JSON only has the one. So attributes are collected under an @attributes key on the object they belonged to.

Keep them, which is the default. Attributes are very often the important part rather than decoration: an id, a type, a href, a currency or unit, a timestamp. Discarding them usually throws away exactly what you needed.

Turn them off only when you know the XML uses attributes purely for things you do not care about, and you want a flatter, easier-to-read result.

Namespace prefixes, and why stripping them is the default

XML from enterprise systems is full of prefixes — soap:Body, xsi:type, dc:creator, atom:link. They make sense in XML and they make awkward JSON keys, because a colon means you cannot reach the value with dot notation: data["soap:Body"] rather than data.soapBody.

Stripping them is the default for that reason, and it is right nearly always. Keep them only when a document genuinely uses two namespaces that share a local name — the same tag meaning different things depending on its prefix — where stripping would collide the two and silently merge unrelated data. That is rare, but in a large SOAP or metadata document it does happen, so if the output looks like two different things have been mixed together, that is the first thing to check.

If the file will not convert

XML is strict in a way JSON is not, and this tool reports the parser's actual complaint rather than silently producing something broken.

One unclosed tag, one bare ampersand in text that was never escaped, one mismatched case in a tag name, and the whole document fails — there is no partial parse. That is by design: XML either is well-formed or it is not.

The error message names the problem and usually the line, which is the fastest route to a fix. The common culprits, in order: an unescaped ampersand or angle bracket in text content; a file that is actually HTML rather than XML; a byte-order mark or stray characters before the declaration; and a truncated download, which is worth ruling out first by checking the file ends where it should.

Data converts well; documents do not

Worth knowing before you convert something complicated.

XML used as data — records with fields, a product feed, a configuration file, an API response, an export — converts cleanly and gives you JSON that is genuinely pleasant to work with. That is the overwhelming majority of what people convert.

XML used as a document does not. Mixed content, where prose is interleaved with inline markup, has no good JSON equivalent: a JSON object cannot preserve the order of differently named siblings, so the sequence of the original is lost. If your XML is DocBook, TEI, an XHTML fragment or anything where reading order is the point, converting it to JSON will produce something valid and useless. Comments are dropped as well, for the same reason.

The element count and depth shown with the result are a quick way to check you got what you expected — if the count looks far too low, the parse probably stopped somewhere you did not notice.

Nothing leaves your browser

The conversion uses the browser's built-in XML parser, so there is no upload and not even a library download. That matters for what XML usually is: an API response with real records in it, a system export, a configuration file with credentials or endpoints, an invoice feed. Pasting one into a web converter hands the whole file to whoever runs it.

Related tools

JSON to XML Converter goes back the other way when a system still expects XML. JSON to CSV Converter flattens JSON records into a spreadsheet, and CSV to JSON Converter is the route when the source is a CSV rather than XML.