There was a time when XML was simply how the web exchanged data. SOAP APIs, RSS feeds, config files, Microsoft Office documents under the hood — all XML. Then JSON showed up, and within a few years it had taken over almost everywhere XML used to dominate. Understanding why helps explain a lot about how modern APIs are designed, and it also explains the specific situations where XML is still the right tool.

The same data in both formats

Here's a small user record in XML:

<user id="1">
  <name>Alice</name>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
</user>

And the same thing in JSON:

{
  "user": {
    "id": 1,
    "name": "Alice",
    "roles": ["admin", "editor"]
  }
}

Already you can see the core difference: XML wraps every value in opening and closing tags (<name>Alice</name>), while JSON uses a colon and lets punctuation do the work. JSON is shorter and, for most developers, faster to read at a glance. XML has something JSON doesn't, though: attributes (like id="1" above) as a distinct concept from child elements — a genuine structural feature, not just a style choice.

Why JSON won for APIs

Where XML still matters

XML didn't disappear, and dismissing it as "obsolete" undersells where it's still the right choice:

The features JSON deliberately left out

JSON's simplicity is a design choice, not an accident. A few things XML has that JSON intentionally doesn't:

Converting between them

The mechanical part of converting JSON to XML is usually straightforward: object keys become element tags, and arrays become repeated sibling elements. The harder decision is what to do with JSON values that don't map cleanly — should a JSON key become an XML attribute or a child element? There's no single correct answer, only conventions, so pick one and apply it consistently. Converting XML to JSON has the reverse problem: XML attributes need somewhere to go in a system that doesn't have a separate concept for them, which is typically solved with a naming convention like prefixing attribute-derived keys with @.

The takeaway

If you're building a new API today, JSON is almost always the right default — the ecosystem, tooling, and developer expectations all point that way. But if you're integrating with an existing enterprise system, working with document formats, or need XML's formal validation and mixed-content handling, XML isn't a relic to be avoided on principle. It's a format with genuine strengths that happen to matter less for the kind of lightweight, JavaScript-adjacent APIs that make up most of the modern web.

Try it yourself

JSON ⇄ XML →

Frequently Asked Questions

JSON's creator, Douglas Crockford, has explained that he left comments out deliberately to keep parsers simple and to avoid people misusing comments to add ad hoc parsing directives, which he'd seen cause problems in other formats. It's a trade-off: you lose the ability to annotate a JSON file, in exchange for a simpler, more predictable format.
Generally yes. XML's parsing model is more complex (elements, attributes, namespaces, mixed content all need to be handled), and XML documents are typically larger for the same data due to closing tags. For high-throughput APIs, this is one of the practical reasons JSON is preferred.
Yes, particularly in enterprise, financial, healthcare, and government contexts where existing SOAP-based systems are deeply embedded, or where the API predates JSON's dominance and has never been rebuilt. Many of these systems also now offer a JSON alternative alongside the legacy XML one.
Unless you're required to integrate with an existing XML-based system, or specifically need XML's document-oriented features (mixed content, formal XSD validation, namespaces), JSON is almost always the simpler, more broadly supported choice for a new integration today.