Attributes are discarded entirely

The converter reads only element structure and text content. An element carrying an id, a type, a unit or a currency attribute keeps its text and silently loses every attribute. For attribute-heavy XML — and a great deal of real-world XML puts most of its meaning in attributes — this can mean losing more information than it keeps.

So <price currency="USD">19.99</price> becomes "price": 19.99, and the fact that this was dollars is gone with no warning. Check whether your document's attributes carry data before you rely on the output; if they do, this tool is the wrong shape for the job.

The single-child ambiguity creates brittle code

Repeated sibling tags become a JSON array; a tag appearing exactly once becomes a plain object or value. That decision is made per document from the data actually present, not from any schema — so a list that happens to hold one item does not produce a one-element array, it produces a bare value.

<people><person>Alice</person></people> gives "person": "Alice", not "person": ["Alice"]. Add a second person and the same field becomes an array. Code written to loop over that field therefore breaks on exactly the inputs where the list is shortest — and those are the inputs least likely to appear in your test fixtures. Normalise defensively: coerce the field to an array before iterating, rather than trusting its shape.

Leading zeros are destroyed by automatic type coercion

Text content is converted to a real type when it looks like one. The exact strings true and false become booleans, and text matching an optional minus sign followed by digits with an optional decimal part becomes a number. This is convenient right up until it is not.

A zip code, product code, bank sort code or account number written with a leading zero matches that numeric pattern. <zipcode>01234</zipcode> becomes "zipcode": 1234 — the leading zero is gone, and with it the validity of the code. Nothing flags this; you get clean-looking JSON with quietly wrong values.

What survives as a string is anything the pattern rejects: a leading plus sign, spaces, letters, or embedded punctuation such as hyphens. So a phone number written with a country-code prefix comes through intact, while a bare digit string does not. If your document contains identifier fields that are digits-only, the practical fix is to post-process the JSON and re-pad them to their known width — do not corrupt the source XML to work around the converter.

Mixed content, structure and errors

Parsing uses the browser's own DOMParser, so everything runs locally and nothing is uploaded. It enforces well-formedness strictly: a malformed document produces an error starting Invalid XML: followed by the browser's own diagnostic, and nothing is converted until the input parses. The result is wrapped in an object keyed by the root element's tag name and printed with two-space indentation.

One last loss to know about: mixed content is not preserved. If an element contains both loose text and child elements, the moment it has children its own text is dropped. This matters for document-oriented XML such as XHTML fragments, where text between tags is the actual content — that kind of markup does not survive this conversion in any useful form.

XML attributes have no natural equivalent in JSON, so any converter has to invent a convention for them — worth checking against your own expectations. The JSON to XML converter reverses the trip.