XML vs JSON: How They Differ and How to Choose

What is the difference between XML and JSON?

XML marks up text, JSON writes down values. That is the root of everything else. An XML document is made of elements that can carry attributes and can mix running text with child elements. A JSON text is a value: an object of named members, an array, a string, a number, a boolean or null.

Three further differences follow. XML has attributes next to child elements, and JSON has only members. XML content is text unless a schema says otherwise, while JSON distinguishes numbers, booleans and strings by its syntax. And XML comes with schema languages of its own, with W3C’s XSD as the main one, whereas neither JSON specification includes one.

What are JSON and XML?

RFC 8259 describes JSON as “a lightweight, text-based, language-independent data interchange format”. It can represent four primitive types, strings, numbers, booleans and null, and two structured ones, objects and arrays. The same syntax is defined in ECMA-404, whose second edition from December 2017 covers the syntax only. In an object, names are expected to be unique, and an object is an unordered collection, while an array is an ordered sequence.

XML 1.0, in its Fifth Edition of 26 November 2008, is a W3C Recommendation. The specification introduces XML as an application profile or restricted form of SGML. It says what a well-formed document looks like and leaves the meaning of the element names to whoever defines the vocabulary.

One neighbour often gets mixed up with both. HTML is neither JSON nor XML: the HTML standard defines two concrete syntaxes, the HTML syntax and an XML syntax, and neither resembles a JSON text.

XML vs JSON: the same data in both formats

The example at the top of the page holds a person with a number, a flag, a name, an address and a list of phone numbers. Both texts were loaded with standard parsers, Python’s json module for JSON and an XML parser for the XML, and the parsed values match.

Look at what changed in the translation. The JSON id and active properties became attributes of the person element, though they could just as well be child elements, and the choice is the author’s. The phones array became a phones element with one phone element per number. In JSON, 17 is a number and true is a boolean. In the XML they are the texts 17 and true until a schema or the reading program assigns a type.

The XML is longer because every element names itself twice, once at the opening tag and once at the closing one. That costs 63 characters here. The figure belongs to this one example and says nothing about size in general, and it shrinks or grows with the shape of the data.

To check that an XML text is well-formed before using it, the XML formatter reports syntax errors in the document.

XML vs JSON comparison table

The schema row connects to XML Schema (XSD). One caution on the word valid: in XML 1.0 itself, valid means conforming to a document type declaration, and with XSD the check is called schema validity. Whenever a document is said to be valid, the schema language belongs in the sentence.

Why use XML over JSON, and is XML outdated?

Whether XML is outdated is a question about numbers, and an answer needs a source with numbers. A question about fit can be answered from the formats themselves.

XML fits when the content is a document. Text with inline markup, such as a paragraph with one emphasised word, is exactly what mixed content is for, and JSON has no direct way to write it. XML also fits when a contract is already written as an XSD, because the schema language belongs to the XML family. The same applies to protocols built on XML: SOAP messages are XML, as SOAP vs REST shows with the same request in both styles.

JSON fits when programs exchange values. A record of numbers, flags and short lists maps straight to the objects and arrays that programming languages already have. A REST web service can use it for its representations, but REST itself does not demand a particular format, and the same resource can be offered as JSON and as XML.

Editorial recommendation, then: choose JSON for plain data between programs, choose XML for documents or when a schema contract in XSD is given, and do not move a working XML interface to JSON merely because the other format feels newer.

Do all JSON parsers read the same text the same way?

Not always, and the specifications explain part of why. RFC 8259 says that names within an object SHOULD be unique and that the behavior of software receiving duplicates is unpredictable. It also lets implementations limit the range and precision of numbers, with IEEE 754 binary64 as the practical basis. ECMA-404 defines the syntax only. It does not require unique names, and it gives the order of name and value pairs no meaning. For text exchanged between systems outside a closed ecosystem, RFC 8259 adds that it MUST be encoded as UTF-8.

The gaps show up in practice. Reading {"a":1,"a":2}, Python’s json module and Node’s JSON.parse both keep the last value, so a is 2. The integer 9007199254740993 stays exact in Python but becomes 9007199254740992 in Node, because Node reads numbers as binary64. Node rejects NaN and comments, while Python’s json.loads accepts NaN, which the standard does not allow. And JSON.stringify writes NaN and Infinity as null.

These results come from one run each of Python 3.13 and Node 25 and describe those versions only. They matter for the choice of format because XML carries values as text, so a schema or a reading program decides how a number is read, while JSON suggests numbers are numbers and leaves the limits to the parser.

Can you convert JSON to XML and back?

Yes, with a rule that both sides agree on. The Open311 wiki, a community source, notes that there is no standard way to map XML attributes into JSON, and it names two conventions: BadgerFish, which keeps attributes and namespaces and loses little, and Parker, which drops attributes.

Four things need a decision whenever a converter runs:

• Arrays. One child element and several look alike in XML. A converter that makes a list only when it sees a repeat gives a single value in one document and an array in the next.
• Attributes. JSON has no place for them, so they become members with a marker in the name.
• Types. XML text such as 17 can become the number 17 or the string "17", and only a schema or a rule can say which.
• Mixed content and order. A paragraph with inline markup has no natural JSON form, and the sequence a, b, a collapses.

The last point can be reproduced. The XML <r><a>1</a><b>2</b><a>3</a></r> maps to {"a":["1","3"],"b":["2"]} in any mapping that groups repeated names into one object, and the order a, b, a is gone.

The XML to JSON converter applies one fixed rule: attributes get an @ prefix, text beside attributes goes under #text, repeated elements become an array, namespace prefixes stay in the key, and every value stays a string. A fixed rule does not remove the losses above; it makes them predictable.