Fast, practical, browser-based developer tools
Convert XML into formatted JSON instantly in your browser. This XML to JSON converter is useful for developers, API testers, backend teams, and anyone transforming structured XML data into JSON for web apps, integrations, analysis, and debugging.
XML is still used in APIs, feeds, enterprise systems, SOAP services, and configuration files. JSON is often easier to work with in modern web applications and JavaScript-based workflows. This tool helps you move between those formats quickly.
This converter is designed to work directly in your browser during normal use. That means your XML input and generated JSON can be processed locally on your device.
For more detail about site usage and analytics, review our Privacy Policy.
Paste XML into the input area, convert it, and then copy or download the generated JSON.
XML
<root>
<user>
<name>John</name>
</user>
</root>
JSON
{
"root": {
"user": {
"name": "John"
}
}
}
XML carries structure that JSON has no slot for — attributes, text mixed with child
elements, ordering, namespaces — so every converter invents its own encoding, and they
disagree. This tool places attributes under an @attributes key; other popular
libraries use @ prefixes on each attribute, a $ object, or an
underscore. Text alongside elements lands under #text, _, or
_text depending on the library.
The upshot: the JSON you get here is not the JSON another tool would produce from the same XML. If code downstream expects a particular shape, it is coupled to one converter's conventions. There is no neutral "the JSON version" of an XML document to standardise on.
This is the bug that bites nearly everyone. XML has no array type, so converters infer lists
from repetition: two <item> siblings become a JSON array, but one
<item> becomes a plain object. That means the same schema
produces items: [ {...}, {...} ] when there are two records and
items: {...} when there is one.
Code written against the two-record case — data.items.map(...) — throws the day
a response happens to contain exactly one. The only robust fix is to normalise: after
conversion, coerce fields you know are collections into arrays before you use them, so the
count of elements in the source never changes your code path.
Three XML features have no clean JSON equivalent. Attributes can collide
with child elements — <user id="1"><id>2</id></user>
has two things called id, and the encoding has to disambiguate them.
Mixed content, where text is interleaved with tags as in
<p>Hello <b>world</b>!</p>, cannot be represented
without either splitting the text into pieces or losing its position relative to the child
element. Namespaces bring prefixes and colons — <ns:tag>
and xmlns declarations — that become awkward keys.
Whitespace is a quieter trap: newlines and indentation between elements are technically
text nodes, and a converter that is not careful will sprinkle empty #text
entries through your JSON.
XML supports a document type definition that can declare external entities, and a classic
attack — XXE (XML External Entity) — abuses this to make a server-side
parser read local files such as /etc/passwd or make outbound requests, and a
related "billion laughs" entity expansion can exhaust memory. A browser's
DOMParser does not resolve external entities, so pasting XML into this page is
safe, but if you build the same conversion into a backend, disable DTD processing and
external entities on the parser. It is one of the most common ways an XML-consuming service
gets compromised.
XML has no array type, so converters infer lists from repetition. One
<item> becomes an object; two or more become an array. Code that
calls .map() then breaks on responses with a single record. Normalise
known-list fields into arrays after converting.
This tool groups them under an @attributes key. That is a convention, not
a standard — other libraries use @ prefixes, a $ object, or
underscores — so JSON produced here will not match JSON produced elsewhere from the same
XML.
The newlines and indentation between XML elements are text nodes. When a document is
pretty-printed, a converter can capture that inter-element whitespace as stray
#text values. It is cosmetic but clutters the output.
In this browser tool, yes — DOMParser does not resolve external entities.
On a server it is a different story: XML External Entity (XXE) attacks can read local
files or trigger requests. If you build this into a backend, turn off DTD and external
entity processing.
They arrive as strings, because XML text content has no type. A value of
<count>5</count> becomes "5", not 5,
unless you coerce it yourself after conversion.