XML predates JSON by close to a decade and was the default choice for web services (SOAP, RSS, most enterprise integration) through the 2000s. JSON did not out-compete it on capability, XML can represent anything JSON can and more; it won on weight and directness for the specific job of moving data between a server and a client.
The same data, two ways
<user>
<name>Ada Lovelace</name>
<age>36</age>
<active>true</active>
<skills>
<skill>mathematics</skill>
<skill>writing</skill>
</skills>
</user>{
"user": {
"name": "Ada Lovelace",
"age": 36,
"active": true,
"skills": ["mathematics", "writing"]
}
}The XML version needs a closing tag for every opening one, and a repeated
<skill> element to represent a list, because XML has no native array
syntax; a <skills> element with several <skill> children could just as
easily be one <skill> child, and only a schema or convention tells a
reader which. JSON’s [ ] says “list” unambiguously in two characters.
Where XML still wins
Attributes alongside content. <price currency="USD">42.00</price>
attaches metadata to a value without inventing a wrapper object. JSON has no
attribute concept; the same data becomes {"price": {"value": 42.00, "currency": "USD"}} or a convention like a @currency key, both less
direct than XML’s native syntax for exactly this shape.
Mixed content. A paragraph of text with inline markup, <p>Some <b>bold</b> text</p>, is XML’s native strength, which is why document
formats (DocBook, most publishing pipelines, SVG) still use it. JSON has no
way to interleave text and markup at all; representing a rich document in
JSON usually means a tree of typed nodes, which is more code to write and
read than XML’s markup already gives you for free.
Namespaces and strict schemas. XML Schema (XSD) and namespaces let a large organization mix vocabularies from different sources in one document without name collisions, with tooling that has existed for over twenty years. JSON Schema exists and does real work (the JSON Schema Generator infers one from a real document), but it is younger and less universally deployed than XSD in large enterprise systems.
Where JSON wins, which is most APIs
Weight. No closing tags means less to transmit and less to parse for the same data, often by a wide margin on deeply nested documents.
Direct mapping to a program’s own data structures. JSON.parse in
JavaScript, or an equivalent one-liner in nearly every other language,
turns a JSON document into that language’s native object and array types
with no intermediate model. XML needs a DOM, or a schema-generated class,
sitting between the text and the data a program actually uses.
No implicit typing questions. Every XML value is text until something
external (a schema, a convention) says otherwise; <age>36</age> is a
string containing “36” unless told to be a number. JSON’s number, boolean,
and null types are explicit in the syntax itself, so there is nothing to
configure or guess.
In practice
New REST APIs default to JSON almost without exception today. XML persists where its own strengths are load-bearing: SOAP services in older enterprise systems, RSS and Atom feeds, SVG and other markup-native formats, and anywhere attributes or mixed content are the actual shape of the data rather than an awkward fit.
Converting between them
The JSON to XML Converter runs both directions,
with controls for namespace prefixes and whether a given value becomes an
XML attribute or a child element, since that choice has no single correct
answer and depends on what is consuming the output. It uses the browser’s
own DOMParser to read XML rather than a hand rolled parser, and every
value comes back a string on the way in, which the tool states rather than
silently guessing at types XML itself does not carry.