Two formats, one job
Both JSON and XML exist to move structured data between systems. For decades XML was the dominant choice. JSON arrived later and gradually took over the web API world — but XML never disappeared. Understanding the differences helps you make an informed choice and read code that uses either format.
A side-by-side example
The same data, represented in both formats:
JSON
{
"book": {
"title": "The Pragmatic Programmer",
"author": "David Thomas",
"year": 1999,
"inStock": true
}
}
XML
<book>
<title>The Pragmatic Programmer</title>
<author>David Thomas</author>
<year>1999</year>
<inStock>true</inStock>
</book>
Both convey the same information. JSON is noticeably more compact — no closing tags.
Syntax
JSON uses two structural characters: {} for objects and [] for arrays. Values are strings, numbers, booleans, null, objects, or arrays.
XML uses elements (<tag>value</tag>), attributes (<tag key="value">), and a small set of special constructs like CDATA sections and processing instructions. XML requires a closing tag for every opening tag, which doubles the character count for element names.
XML also supports namespaces (<ns:element xmlns:ns="...">), which JSON has no equivalent for.
Readability
For everyday use, JSON is easier to read at a glance. The structure is immediately visible — indented JSON maps directly to the mental model of nested data.
XML becomes harder to read as depth increases, because closing tags repeat the element name and the visual nesting can be hard to follow.
That said, XML has one readability advantage: attributes can disambiguate metadata from data:
<user id="1042" active="true">
<username>alice</username>
</user>
In JSON everything is a value, so "metadata" and "data" are represented identically.
Data structures
| Feature | JSON | XML |
|---|---|---|
| Objects / maps | { "key": "value" } | <key>value</key> (element approach) |
| Arrays / lists | [1, 2, 3] | Repeated elements or a wrapper element |
| Attributes | Not supported | <elem attr="val"> |
| Comments | Not supported | <!-- comment --> |
| Binary data | Not supported natively | Via Base64 in text content |
| Namespaces | Not supported | Full namespace support |
| Schema validation | JSON Schema (separate standard) | XML Schema (XSD) — built into the ecosystem |
Type handling
JSON carries type information inline: the value 42 is a number, "42" is a string, and true is a boolean. Parsers reconstruct the correct type without extra hints.
XML carries no type information. Everything is text. If you need types, you add an XML Schema (XSD) and validate against it, or you use xsi:type attributes — both add complexity.
Common use cases
JSON is typically used for:
- REST API responses and requests
- Browser-to-server communication (fetch, XHR)
- Configuration files in JavaScript toolchains (
package.json,.eslintrc.json) - NoSQL document databases (MongoDB, CouchDB, Firestore)
- Mobile app data exchange
XML is typically used for:
- Enterprise integrations and legacy systems (SOAP web services)
- Document formats: DOCX, XLSX, SVG, XHTML
- RSS and Atom feeds
- Android layout files (
layout.xml) - Configurations in Java ecosystems (Maven
pom.xml, Spring XML config) - Industries with strict schema requirements: healthcare (HL7), finance (FIX/FIXML)
When to choose which
Choose JSON if you are building a new web API or working in a JavaScript environment. It integrates naturally with JavaScript's object model, every modern HTTP client understands it, and it is simpler to work with.
Choose XML if you are integrating with an existing enterprise system that already speaks XML, if you need features like comments, namespaces, or XSLT transforms, or if your industry mandates a specific XML-based standard.
In practice, the choice is often not yours to make — if you are consuming a third-party API, you work with whatever it returns. Both formats are well-supported in every programming language.