← Back to JavaScript Course | Chapter 9: Async & Web APIs | Lesson 26 of 26

JS JSON vs XML

Before JSON became the dominant data-interchange format, XML was the standard choice for structured data on the web -- understanding the practical differences between the two, and why JSON largely won out for most modern web APIs, helps explain both current conventions and why some older or specialized systems still use XML.

Comparing the Same Data in Both Formats

The same structured data looks noticeably different in each format -- JSON's syntax (curly braces, colons, square brackets) closely mirrors JavaScript object and array literals directly, while XML's tag-based syntax more closely resembles HTML, with opening and closing tags wrapping each piece of data.

Note: Notice how JSON's structure maps almost one-to-one onto JavaScript's own object/array syntax, which is a major reason it integrates so naturally into JavaScript code.

Warning: A deeply nested XML document can be visually harder to scan than the equivalent JSON, purely due to the repeated opening and closing tags at every level.

Example: Comparing the Same Data in Both Formats

javascript
const json = { name: "Sam", age: 30 };
const xml = "<person><name>Sam</name><age>30</age></person>";
console.log(JSON.stringify(json));
console.log(xml);

Parsing Complexity: JSON vs XML

JSON.parse() converts a JSON string directly into a usable JavaScript value in one built-in call, while parsing XML requires DOMParser and then navigating the resulting document with DOM methods like querySelector() -- noticeably more steps for the same basic goal of "get the data into a usable form".

Note: For a brand-new project with no existing XML dependency, the simpler JSON parsing path is a strong reason to default to JSON.

Warning: Reading a deeply nested XML structure requires chaining several DOM navigation calls, compared to simply accessing nested properties directly on a parsed JSON object.

Example: Parsing Complexity: JSON vs XML

javascript
const obj = JSON.parse('{"name": "Sam"}');
console.log(obj.name); // one call

const doc = new DOMParser().parseFromString("<name>Sam</name>", "text/xml");
console.log(doc.querySelector("name").textContent); // several steps

Features JSON Lacks That XML Has

XML supports attributes (extra metadata on a tag, like <book id="42">), namespaces (avoiding naming conflicts when combining vocabularies), comments, and mixed content (text interspersed with child elements) -- none of which JSON has a native, direct equivalent for.

Note: When a data format genuinely needs rich metadata alongside content (like document markup with inline formatting), XML's feature set may be a better structural fit than forcing it into JSON.

Warning: Representing something XML expresses naturally (like mixed text-and-markup content) in JSON usually requires an awkward workaround, since JSON has no concept directly analogous to it.

Example: Features JSON Lacks That XML Has

javascript
const doc = new DOMParser().parseFromString('<book id="42">Title</book>', "text/xml");
console.log(doc.querySelector("book").getAttribute("id")); // no JSON equivalent

Why JSON Became the Default for Web APIs

JSON's tight fit with JavaScript (no separate parsing library needed), its more compact size (less repeated markup than XML's opening/closing tags), and its simplicity for the vast majority of typical API data (nested objects and arrays, without needing attributes or namespaces) are the main reasons it overtook XML as the default choice for most new web APIs.

Note: Default to JSON for any new API you design, reserving XML specifically for integration with an existing system that already requires it.

Warning: JSON's simplicity is also a limitation -- for genuinely complex, document-like data with rich structural needs, that same simplicity can become a real constraint XML would not have.

Example: Why JSON Became the Default for Web APIs

javascript
console.log(JSON.stringify({ name: "Sam" }).length);
console.log("<person><name>Sam</name></person>".length);

When XML Is Still the Right Choice

XML remains genuinely appropriate for document-centric formats (like RSS feeds, SVG, or Office document formats), systems requiring formal schema validation (XSD), and integration with existing enterprise or SOAP-based systems that were built around it long before JSON became common.

Note: When integrating with an existing system that already uses XML (like an established enterprise API or a legacy feed format), work with XML directly rather than forcing an unnecessary conversion layer.

Warning: Converting a well-established, working XML-based integration to JSON purely for the sake of using a "more modern" format, when nothing about the actual requirements calls for it, is often unnecessary extra work.

Example: When XML Is Still the Right Choice

javascript
const doc = new DOMParser().parseFromString("<rss><item>News</item></rss>", "text/xml");
console.log(doc.querySelector("item").textContent);
Common Mistakes
  1. Assuming XML is simply worse or obsolete -- it remains genuinely well-suited for certain use cases, like documents with rich structural markup (similar to HTML) or systems with strict, formal schema validation needs.
  2. Choosing XML for a brand-new project purely out of unfamiliarity with JSON, when JSON is almost always the simpler, more appropriate default choice today.
  3. Forgetting that converting between JSON and XML is not always a clean one-to-one mapping, since XML supports concepts (like attributes vs. elements) that JSON has no direct equivalent for.
Chapter Summary
  • JSON is generally more compact, maps directly onto native JavaScript objects/arrays, and requires no separate parsing library.
  • XML supports richer structural features (attributes, namespaces, mixed content) and has mature schema validation tooling (XSD, DTD).
  • Most modern web APIs default to JSON; XML remains common in specific domains like enterprise systems, SOAP-based APIs, and document-centric formats.
Browser Support

JSON.parse()/stringify() and DOMParser (for XML) are both natively supported in every modern browser, so working with either format requires no external library.

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.