Converting XML to JSON sounds like a mechanical step, but the two formats do not hold the same things. XML has attributes next to child elements, text that can sit between elements, and names that belong to namespaces. JSON has objects, arrays, strings, numbers, booleans and null. Every converter has to decide where the extra parts go, and no single decision is standard.
This converter makes those decisions in the open. It reads the XML with the browser's own parser, applies the rules below and shows the JSON next to the input. The text is processed in the open tab and is not sent to a server, so confidential documents can be tried without a copy leaving the machine.
How to convert XML to JSON online
- Paste the XML into the input field, or start from the example document.
- Start the conversion. The JSON appears in the output field.
- If the input is not well-formed, the page reports an error instead of producing JSON. Read the message and fix the earliest problem first, because later complaints are often consequences of it.
- Copy the result. Check it against the rules below whenever the document uses attributes, namespaces or mixed content.
The error text comes from the browser. The HTML Standard leaves the content of the parser error open, so the wording and the reported position can differ between browsers. The XML formatter uses the same kind of parser and is the quicker place to find out why a document does not parse.
How XML attributes and text become JSON
There is no standard way to map arbitrary XML to JSON. The Open311 wiki, which compares the common conventions, says so directly, and the Python library xmljson lists several of them: BadgerFish with @ for attributes and $ for text, GData with $t, and Parker, which the wiki calls lossy because it ignores attributes. This converter follows its own rule, which is short.
| XML | JSON |
|---|---|
| Element with text only | "name": "Schema Handbook" |
| Element with attributes only | "price": { "@currency": "USD" } |
| Element with attributes and text | "price": { "@currency": "USD", "#text": "39.00" } |
| Repeated sibling elements | "tag": ["a", "b"] |
| Prefixed element | "dc:title": "Example" |
Attribute names get an @ in front, so an attribute and a child element with the same name stay apart. Text that sits beside attributes is stored under #text. Text without attributes needs no wrapper and becomes a plain string. Characters that need escaping in XML, such as an ampersand, arrive as ordinary characters in the JSON string.
Repeated elements and element order
When an element name occurs several times under the same parent, the converter writes an array. When it occurs once, the value stays a single string or object. That is convenient to read but easy to trip over: code that expects an array breaks on the document that happens to contain only one item, and code that expects a single value breaks on the one with two. A consumer should accept both shapes.
The second limit is order. The RFC for JSON describes an object as an unordered collection of name and value pairs, and ECMA-404 gives the order of pairs no meaning either. Arrays are ordered, but only within one name. Take the siblings <a>1</a><b>2</b><a>3</a>. In the JSON they become "a": ["1", "3"] and "b": "2", and the fact that b came between the two a elements is gone.
If the sequence carries meaning, keep it somewhere that survives, for example in an attribute that numbers the items, or process the XML with a tool that works on the document tree. The XML Recommendation does not treat the order of attributes as significant, so that order is the one thing that needs no protection.
XML namespaces in JSON
In XML, a prefix such as dc is only a placeholder for a namespace name. The element's real identity is the expanded name, made of the namespace URI and the local name. JSON has no such concept, so a conversion must either keep the prefix or write out the URI.
This converter keeps the prefix in the key, as in "dc:title". The result reads well and is easy to match, but it carries a consequence: two documents that bind different prefixes to the same namespace produce different keys, even though the elements are the same in XML terms. A prefix can also mean different URIs in different parts of one document.
Attributes follow a separate rule in the Namespaces in XML Recommendation: a default namespace applies to element names but does not apply directly to attribute names without a prefix. An unprefixed attribute is therefore not in the default namespace, and a key such as @currency says nothing about it. When the namespace of a name matters downstream, the document should declare it with a prefix that the receiving side agrees on.
Mixed content does not map cleanly to JSON
Mixed content is an element that contains text and child elements together, like a sentence with a bold word: <p>Read the <b>full</b> text.</p>. The XML Recommendation allows character data to be mixed with child elements, and a declaration can constrain the types of the children but not their order or number of occurrences. The text before and after b is part of the meaning.
An object has no position. A key for b and a key for the text can each be stored, but not the fact that the text was split in two by b. Any object-based mapping therefore changes the sentence structure, and a conversion back cannot rebuild it. Documents of this kind, such as articles, manuals or markup in running text, are usually better kept as XML. For data records with a few fields, the problem does not arise.
Whitespace is a related detail. The specification requires a parser to pass every character that is not markup on to the application, so indentation between elements reaches the converter as well. Check elements with mixed content in the output before relying on them.
Numbers, booleans and null: XML only has text
XML 1.0 knows character data and nothing else. The text 39.00 is a string of characters until a schema says otherwise, and the datatypes of XML Schema Part 2 are the usual place where such a statement is made. The converter does not guess. Every value in the output stays a string, so 39.00 arrives as "39.00" and the trailing zeros survive.
This avoids a quiet class of errors. JSON numbers are specified loosely: RFC 8259 notes that interoperability is good for software that expects no more range and precision than IEEE 754 binary64. In a test, Python read 9007199254740993 exactly, while the JavaScript function JSON.parse returned 9007199254740992. A string cannot lose digits that way, and the receiving code decides when to convert it.
The same holds for booleans and null. The words true and false in XML text are only text. Where the vocabulary defines types, the XML Schema carries that information, not the instance.
Other formats XML can be converted to
JSON is one target among several. Reformatting stays within XML and changes only layout, which the XML formatter handles. The neighbouring configuration format has its own page: the YAML to JSON converter turns YAML into JSON in the same local way.
The W3C also describes a conversion function, fn:xml-to-json in XPath Functions 3.1, but it applies only to a fixed XML representation of JSON, not to arbitrary XML. That is another sign that mapping general XML needs a convention of its own.
Where JSON replaces XML and where it does not
JSON suits interfaces that exchange records: a small set of types, direct mapping to the objects and lists of most programming languages, and no schema machinery by default. XML suits material with structure beyond that: attributes, namespaces, schema languages, and text with markup inside. The two overlap in many web interfaces, which is where the question of replacement comes from.
What a conversion loses depends on its direction, and XML to JSON must decide about everything described above. For a longer comparison of the formats, see XML vs JSON.
How the converter is defined
The page parses input with the browser's XML parser and applies the mapping from the table above, nothing more. It makes no network request of its own. It converts in one direction, from XML to JSON. Mixed content and element order are the cases the mapping cannot preserve, as described above, and the output shows what remains after the rule is applied.
Frequently asked questions
01Is XML replaced by JSON?
Not in any way that can be shown here. Both formats are in use, and they suit different material: JSON fits plain records and lists, XML fits documents with attributes, namespaces and text that contains markup. The more useful question is which one a given interface already speaks.
02Why use JSON over XML?
JSON has a small set of value types and maps directly to the objects and lists of most programming languages, so reading it needs little ceremony. XML offers more, including attributes, namespaces and schema languages, and that extra weight is what a conversion has to flatten. When the data is a simple record, JSON is usually the lighter fit.
03What can XML be converted to?
XML can be rewritten as JSON, as readable XML with different indentation, or as a table such as CSV when the content is regular. Each target drops something: JSON has no attributes or mixed content, and CSV has no nesting. The choice depends on what the receiving side needs.