XML to JSON
The awkward parts of this conversion are attributes, repeated elements and types. Here they are settings you can see, not guesses made for you.
XML and JSON do not describe the same shapes
This is the part every converter has to make a decision about, and most of them make it silently. XML has three things JSON has no slot for: attributes, ordered mixed content, and the fact that an element appearing once looks identical to an element that could appear many times.
The choices here are yours to make and visible in the output as you make them. Attributes can be prefixed with @ (the convention from BadgerFish and the one most APIs use), prefixed with _, grouped together under a single $ key, merged in as ordinary keys, or dropped. Text inside an element that also has attributes or children lands under a key you choose — #text by default.
The repeated-element trap
Take an order with three line items. Every converter turns <lines> into an array of three. Now take the same order with one line item: the natural conversion gives you an object, not an array of one, and the code you wrote yesterday breaks today on a perfectly valid document.
There is no way for a converter to know which elements repeat without the schema, so there are only two honest options. Leave it as it is and handle both shapes in your code, or tick always use arrays and get arrays everywhere — consistent, more verbose, and safe to iterate. If the JSON is going into a program rather than a human, the second option saves you a bug.
Leaf elements collapse
An element with nothing but text and no attributes becomes the string itself, not an object wrapping a #text key. So <name>R. Okonkwo</name> gives you "name": "R. Okonkwo". Without that rule, a document of any size produces JSON where every value is buried one level deeper than it needs to be, and nobody wants to read it.
Empty elements — <note/> and <note></note> alike — become an empty string. That is a choice, not the only answer; JSON null would be defensible too, but an empty string matches what the XML actually says, which is that the element is present and carries no text.
Types, namespaces and the things that go wrong
XML has no types. Everything between the tags is text, and 42 is the characters four and two. Type conversion is therefore off by default, and when you turn it on we still refuse to touch anything with a leading zero — because a postcode, a part number or an employee ID of 007 silently becoming 7 is the kind of bug that surfaces six months later in someone else's report. Integers beyond JavaScript's safe range stay as strings for the same reason.
Namespace prefixes are stripped by default: <soap:Envelope> becomes Envelope. Almost everyone wants this, because the prefix is an artefact of the document rather than part of the data. Untick it if the prefixes carry meaning in your case — for instance when two namespaces genuinely define elements of the same local name.
Parsing is done by the XML parser already inside your browser, so what counts as well-formed here is exactly what counts as well-formed everywhere else. If something is malformed you get the parser's own message — an unclosed tag, a stray ampersand, a mismatched close — rather than a vague failure. Comments, processing instructions and the XML declaration are ignored; CDATA sections are read as ordinary text.
Common questions
Why did my single item not come out as an array?
Because nothing in the XML says it could repeat — that information lives in the schema, which a converter does not have. Tick “always use arrays for child elements” to get arrays everywhere, which is the safe choice when the JSON is going into code.
What happens to attributes?
Whatever you choose. The default prefixes them with @, matching the convention most APIs use. You can also prefix with an underscore, group them all under a $ key, merge them in as ordinary keys, or leave them out entirely.
Are numbers converted automatically?
No, and that is deliberate. XML has no types, so everything is text until you say otherwise. Tick the box and numbers and booleans are converted — except anything with a leading zero, which stays a string so that reference numbers survive.
Does it handle namespaces?
Prefixes are stripped by default, so soap:Envelope becomes Envelope. Untick the option if your document relies on prefixes to tell two same-named elements apart.
Can it convert JSON back to XML?
Not here. The round trip is lossy in a way that is hard to hide — the JSON no longer records which values were attributes, what order mixed content was in, or what the namespaces were, so the XML you got back would be a guess.
How large a file can it take?
Large ones. It is bounded by the memory of your tab rather than an upload limit. Multi-megabyte documents convert in a moment; extremely large ones may pause the tab while the parser works.
Is anything sent to a server?
No. Your browser's own XML parser does the reading and the conversion happens in this page, so the document never leaves your machine. That matters for the kind of XML people actually have — invoices, payroll exports, SOAP payloads.