XML to JSON Converter — Free & In Your Browser
Legacy XML in, workable JSON out — attributes and repeated elements mapped predictably.
🔒 Runs in your browser — files never uploaded ⚡ No signup 💯 Free
Convert XML to JSON you can actually work with — for the SOAP response, the RSS feed, the decades-old export that every modern tool refuses to read. Attributes, nested elements, repeated elements and mixed text all map by a predictable convention, and malformed XML gets a clear error rather than a shrug.
Parsing uses the browser's own XML engine, locally — feeds and exports never leave your machine.
How to use XML to JSON
- Paste XML into the left pane.
- Read the JSON on the right — it updates live.
- Copy or download as a .json file.
The mapping, precisely
- Elements become keys. The root element becomes the top-level key.
- Attributes become
@namekeys — kept distinct from child elements because XML treats them differently and collapsing them loses information. - Repeated siblings become arrays: three
<item>elements produce anitemarray. (Note the classic XML→JSON wrinkle: ONE<item>produces a plain value, not a one-element array — if your consuming code expects arrays, guard for both.) - Text beside children becomes
#text; an element with only text becomes just that string.
Everything arrives as strings
XML has no types, so <born>1815</born> becomes "1815", the string. Converting values to numbers is a schema decision the consumer should make knowingly — silent guessing is how postcodes lose their leading zeros.
Namespaces
Namespaced tags keep their prefixes as written (soap:Body becomes a "soap:Body" key). That's the honest lossless choice; stripping prefixes can merge elements that are genuinely different.
Related
Mirror direction: JSON to XML, using the same conventions — the two round-trip cleanly.
Frequently asked questions
Why is one element an object but two are an array?
The classic XML→JSON wrinkle: repetition is the only signal XML gives for "this is a list", so one <item> maps to a value and several map to an array. Consuming code should guard for both — or the producing side should always send a schema-guaranteed count.
Where did my attributes go?
Into @-prefixed keys: <person id="1"> gives "@id": "1". Element text sitting beside child elements lands in "#text". Nothing is discarded.
Why are all values strings?
XML has no types — <born>1815</born> is text that looks like a number. Guessing types silently corrupts data (leading zeros, version strings), so this converter leaves conversion to code that knows the schema.
Does it handle SOAP responses and namespaces?
Yes — namespaced tags keep their prefixes as keys ("soap:Body"), which is lossless. Malformed XML — the other SOAP speciality — produces a clear parser error instead of half a result.