JSON vs XML: Why One Won

Twenty years ago, XML was the default format for APIs and configuration alike. Today almost every new API ships JSON first, if it offers anything else at all. The reasons come down to three practical differences, not ideology.

Same data, less to type

<!-- XML -->
<user>
  <name>Ada</name>
  <age>30</age>
</user>

// JSON
{"name": "Ada", "age": 30}

XML requires an opening and closing tag for every value. JSON needs neither — just a key, a colon, and a value. Over a large payload, that difference adds up to meaningfully less data to send and parse.

JSON is JavaScript's native shape

JSON — JavaScript Object Notation — maps directly onto JavaScript objects and arrays with zero translation. As the web shifted toward JavaScript-heavy frontends, being able to write const data = JSON.parse(response) and immediately use the result as a normal object was a meaningful convenience XML never offered.

No schema required to get started

XML's ecosystem leans on schemas (XSD, DTDs) to define and validate structure — powerful, but it's ceremony you have to set up before you can use the data at all. JSON works fine with no schema whatsoever; you can start sending and parsing it immediately, and add validation later only if you need it.

Where XML still wins

XML isn't dead — it's just specialized now. It remains common in enterprise systems, document formats (like .docx and .xlsx, which are XML under the hood), and anywhere you genuinely need mixed content (text with embedded markup) or strict, enforced schemas. JSON has no clean way to represent "a paragraph of text with a bold word in the middle" — XML does that naturally.