Learn / XML / XML vs JSON
Lesson 4 of 6

XML vs JSON

Two formats, two philosophies. JSON reads like the data structures programmers already think in — objects and arrays. XML reads like a document — nested, labelled, and built to describe rich structure, not just values. Neither one is simply "better" — they were built to be good at different jobs, and knowing which job you have is the whole game.

💡 The Bottom Line

JSON is terser and maps directly onto objects/arrays, which makes it the default choice for REST APIs and config files. XML is more verbose but supports things JSON simply has no equivalent for — attributes, mixed content, namespaces, and mature schema languages — which makes it the right choice for rich documents and systems that already require it.

The same data, two ways

XML

<book id="123">
  <title>Dune</title>
  <author>Frank Herbert</author>
  <year>1965</year>
</book>

JSON

{
  "id": 123,
  "title": "Dune",
  "author": "Frank Herbert",
  "year": 1965
}

Same information, roughly the same amount of typing here — but notice XML repeats every tag name twice (once to open, once to close), while JSON's braces and commas carry no repeated naming at all. That difference compounds fast in larger, deeply nested documents.

Where the two genuinely differ

🔑 Key Distinction: verbosity

XML's closing tags repeat the element name (<title>...</title>); JSON has no equivalent repetition. For large documents, this makes XML noticeably heavier over the wire and slower to hand-write.

🔑 Key Distinction: mixed content

XML can freely interleave plain text with markup inside a single element — called mixed content:

<p>Hello <b>world</b>! Welcome to <i>XML</i>.</p>

JSON has no equivalent at all for this. A JSON string is just an opaque blob of text — it can't have a "bold" or "italic" span marked up inside it without inventing your own ad-hoc convention. This is precisely why rich-text and document formats (like the XML inside a .docx file) are still built on XML, not JSON.

🔑 Key Distinction: attributes

XML has a whole separate mechanism — attributes — for metadata on an element (Lesson 3). JSON has no attribute concept; every piece of data is just another key in an object.

🔑 Key Distinction: schema languages

XML has had mature, standardized schema languages — DTD and later XML Schema (XSD) — since the early 2000s, years before JSON Schema existed as a comparable standard for JSON. If you need to formally define and validate a document's shape and XML is already your format, the tooling has been battle-tested for a very long time.

🔑 Key Distinction: comments

XML natively supports comments:

<!-- this is a comment, ignored by parsers -->
<book>...</book>

JSON has no comment syntax at all — as covered in the JSON track's own gotchas lesson, this trips up plenty of developers writing JSON config files by hand.

⚠️ Watch Out

Don't pick a format out of habit. If you're designing something new and it's a simple data interchange job — a REST API response, a config file — JSON's simplicity usually wins. If you're producing a document with rich, mixed content, or you're integrating with a system that already speaks XML (SOAP, Office formats, an existing enterprise pipeline), fighting that with JSON creates more problems than it solves.

When to reach for which

Reach for XML when...

  • You have documents with mixed content or rich text
  • You need a namespace system to combine vocabularies
  • You're integrating with legacy or mandated formats (SOAP, Office, SVG)

Reach for JSON when...

  • You're building a REST API
  • You're writing a config file
  • Simplicity and fast parsing matter more than document richness

🙋 There Are No Dumb Questions

Q: Can I just convert between the two?
A: For simple, JSON-shaped data — objects and arrays of plain values — yes, largely mechanically. But anything using XML attributes, mixed content, or namespaces doesn't have a clean 1:1 JSON equivalent, so conversion tools have to make judgment calls (e.g., turning attributes into oddly-named keys like "@id"). That awkwardness is itself a sign of how different the two models really are under the hood.

🔧 Try It Yourself

Take the mixed-content example above — <p>Hello <b>world</b>!</p> — and try to write it as JSON without losing any information about where the bold text starts and ends. Notice how awkward it gets; that awkwardness is the point of this lesson.

✅ Quick Check

Which capability does XML have that JSON has no equivalent for at all?

Next up: how a parser actually turns XML text into something your code can work with — and the two very different strategies for doing it.

← Back to
Next →