Convert XML to JSON

The structure converts in a second. The disagreement is the work

Turning elements into keys is the easy half, and it is the half every converter shows you. An element with children becomes an object, an element with text becomes a string, and the nesting carries over one level at a time. You can write that in an afternoon. What nobody shows you is that XML and JSON do not describe the same kind of thing, so a whole category of what your document says has nowhere to land — and the usual response is to drop it and present the result as a successful conversion.

XML has attributes, which JSON does not. It has namespaces, which JSON does not. It has an ordering between siblings with different names, and JSON objects have no ordering between keys at all. It has mixed content, where text and elements interleave inside one element, and there is no JSON shape for that. It has comments, processing instructions, CDATA sections and a DOCTYPE. None of those survive. The question is never whether something is lost; it is whether you were told.

XML to JSON in ten kinds of loss, counted and named

This converter keeps a ledger. Every time it meets something that cannot cross the gap it records which kind it was, and the receipt lists each kind once with a count and with the consequence spelled out for whoever reads the JSON afterwards. Comments, processing instructions, a DOCTYPE, CDATA wrappers, namespace bindings, mixed content, sibling ordering, empty elements, insignificant whitespace and key collisions each have their own entry. If your document contains none of them, the receipt says that too, in as many words, because a lossless conversion is a real result and deserves to be stated rather than implied by an absence.

Two of those entries deserve their own sentence. A namespace prefix is carried into the key, so <soap:Body> becomes the key "soap:Body". That keeps the characters, and the round trip closes, but the JSON does not mean the namespace — it only carries it. Two documents that a namespace-aware reader treats as identical can produce different JSON here, and that is worth knowing before you match on key names downstream. Mixed content is the harder one: it is the single case where the round trip genuinely does not close, because the interleaving of text and elements has no representation in an object. It is reported as a loss rather than quietly flattened.

Every value comes out as a string, and that is a decision

A postal code written 01606 is not the number 1606. An identifier of nineteen digits is not the floating point number nearest to it. Without a schema, XML has no types at all — the characters between two tags are characters, and nothing in the document says otherwise. A converter that guesses types is making an irreversible change to your data on the strength of a pattern match, and the two examples above are the everyday cases where it gets it wrong. Strings are the only mapping that is reversible for every value. If you know a particular field is numeric, your own code can convert that field, and it can do so correctly because it knows something this tool cannot.

The array setting answers a question your document cannot

When one <item> becomes an object and two become a list, the shape of your JSON depends on the contents of the file you happened to convert. Code written against the first file breaks the day a second item appears. That is not a bug in the converter; it is the honest reading of a document that only ever showed one. So the choice is yours: keep the faithful shape, or set every child element to be a list regardless, so that the shape stays fixed while the content varies. Almost no converter offers the second option, and it is the one you want when the JSON feeds a program rather than a person.

Where this sits among the other tools

Going the other way is a separate tool on its own address: the JSON to XML converter shares this exact mapping, so a document that survives one direction survives the other. If the XML will not read at all, the XML validator reports what is wrong with a line and a character rather than a refusal, and the XML formatter lays it out over lines first. On the JSON side, the JSON formatter takes the output and re-indents or minifies it. If what you actually need is a schema describing the document rather than a different serialization of it, the XSD generator derives one. And spreadsheets have their own route in CSV to XML.

Nothing leaves the tab

Your document is read where it already is. There is no upload, no endpoint, and no request carrying any part of it anywhere; nothing about what you paste is written to a log or to the address bar. Size is never a refusal either — a large file is converted like any other — but the advice about what it will cost in memory arrives before the work begins rather than once the tab is already labouring, and past 64 KB the parser moves to a worker so scrolling and typing stay smooth while it grinds.