XML vs JSON: When to Use Each Format in Modern APIs

XML did not die — and this comparison still matters

Every few years, a wave of blog posts declares XML dead. JSON won. Move on. And yet, in 2026, XML is quietly powering an enormous share of the systems that the internet actually runs on. SOAP web services used in banking and healthcare still exchange XML envelopes. RSS and Atom feeds are XML. SVG — every icon in your design system, every chart in your dashboard — is XML. Android resources, Maven build files, Gradle configurations, SAML authentication tokens, Office Open XML (the format behind every .docx and .xlsx file), and OpenDocument files are all XML. Enterprise integrations that have been running reliably for fifteen years are not getting rewritten because JSON is fashionable.

So the practical question for a developer in 2026 is not "which format won?" It is "when should I reach for each one?" JSON is the clear default for new REST APIs and browser-facing data. But there are specific domains and specific technical requirements where XML is genuinely the better choice — and confusing the two leads to real problems. This article gives you a concrete framework for making that call.

The fundamental difference: markup language vs. serialization format

The comparison is often framed as a syntax contest — angle brackets vs. curly braces — but the real difference is conceptual. XML is a markup language. It was designed to describe documents where the relationship between text and structure matters. An XML element can contain text, child elements, and more text interleaved — what the spec calls mixed content. Attributes carry metadata about elements. Namespaces let you combine vocabularies from multiple standards in a single document without name collisions. Comments are part of the format. The entire model reflects the original problem XML was built to solve: structured documents like HTML, legal contracts, and configuration files where ordering is semantically meaningful.

JSON is a data serialization format. It was designed to represent objects, arrays, strings, numbers, booleans, and null — the primitive types of JavaScript — in a form that is compact, easy to parse, and directly mappable to the data structures of most programming languages. JSON has no concept of attributes, namespaces, mixed content, or comments. It does not try to be a document format. It tries to be the simplest possible wire representation for structured data moving between systems. That simplicity is both its greatest strength and its ceiling.

The same data in both formats

The verbosity difference becomes concrete when you look at the same data structure expressed in both formats. Here is a product record with a nested array of size variants:

JSON

{
  "product": {
    "id": "SKU-8821",
    "name": "Trail Running Shoe",
    "price": 129.99,
    "inStock": true,
    "variants": [
      { "size": "US 9",  "color": "Slate", "qty": 12 },
      { "size": "US 10", "color": "Slate", "qty": 4  },
      { "size": "US 11", "color": "Slate", "qty": 0  }
    ]
  }
}

XML

<?xml version="1.0" encoding="UTF-8"?>
<product id="SKU-8821">
  <name>Trail Running Shoe</name>
  <price>129.99</price>
  <inStock>true</inStock>
  <variants>
    <variant size="US 9"  color="Slate" qty="12" />
    <variant size="US 10" color="Slate" qty="4"  />
    <variant size="US 11" color="Slate" qty="0"  />
  </variants>
</product>

The XML version is about 30% more characters for equivalent data. The difference grows with deeply nested structures because every element requires both an opening and closing tag. The JSON version also maps directly to a JavaScript object with no transformation — JSON.parse() returns something your code can use immediately. The XML version requires a parser that understands the DOM or an XML-to-object library. For simple data exchange, JSON wins on almost every practical metric.

Where JSON wins

JSON is the right default for the majority of new API work. The advantages are concrete, not just stylistic.

Where XML wins

XML's advantages are real but domain-specific. In each of these areas, the format provides capabilities that JSON simply does not have.

Domains where XML is dominant

Some technical domains have standardized on XML and are unlikely to change. If you are working in any of these areas, XML is not a choice — it is a requirement.

For all of these, the question of "should I use XML?" is already answered. The question becomes how to work with XML effectively — which is where a good formatter and validator saves significant time. The XML Formatter handles indentation, syntax highlighting, and validation so you can inspect and debug XML payloads without fighting the raw markup.

The attribute vs. element debate in XML

One of the most common design mistakes in XML is misusing attributes and child elements. Both can represent data, which leads to inconsistent schemas where some values are attributes and others are child elements for no principled reason. The conventional rule is:

Use attributes for metadata about the element

Attributes describe properties of the element itself — its identifier, its version, its type. In the product example above, id="SKU-8821" as an attribute is appropriate because it identifies the element, not the data it contains.

Use child elements for data that belongs to the document

The product name and price are content — they belong as child elements, not attributes. The practical reason is that attributes cannot contain child elements, cannot have their own attributes, and cannot appear more than once per element. If a field might ever become complex, use a child element.

<!-- Avoid: burying data in attributes -->
<product id="SKU-8821" name="Trail Running Shoe" price="129.99" />

<!-- Prefer: attributes for identity, elements for content -->
<product id="SKU-8821">
  <name>Trail Running Shoe</name>
  <price currency="USD">129.99</price>
</product>

Performance: parsing speed and payload size

JSON parsing is measurably faster than XML parsing in browser environments. The V8 engine (Chrome, Node.js) and SpiderMonkey (Firefox) have highly optimized native JSON parsers. XML parsing requires constructing a DOM tree, which involves more allocations, more traversal, and more memory overhead for equivalent data. For browser-heavy workloads — dashboards, single-page apps, mobile web — this difference is meaningful.

For server-to-server communication, the difference is less significant. Mature XML libraries like libxml2 (used in Python, PHP, Ruby, and many others) and Saxon parse XML very efficiently, and at the scale of a single inter-service call the parse time is rarely the bottleneck. Payload size is still a factor — XML overhead is real over millions of requests — but the raw parse speed argument is weaker in a pure server context than it is in the browser.

The hybrid approach: content negotiation

Some APIs serve both formats and let the client declare which it prefers using the HTTP Acceptheader. This is called content negotiation and it is a legitimate pattern for APIs that need to serve both modern JavaScript clients and legacy enterprise consumers.

# Request JSON
GET /api/products/SKU-8821
Accept: application/json

# Request XML
GET /api/products/SKU-8821
Accept: application/xml

Content negotiation adds server complexity — you need to serialize the same data model into both formats — but it is valuable when your API needs to bridge ecosystems. Spring Boot, ASP.NET Core, and most enterprise Java frameworks support content negotiation out of the box with minimal configuration. If you are building a new API that only has JavaScript and mobile clients, skip it and default to JSON. If you are building an API that enterprise systems will integrate with via SOAP-like tooling, consider offering XML.

Decision guide: which format to choose

The choice is rarely ambiguous once you map your situation to the criteria below.

When you are working with either format and need to inspect, validate, or clean up the structure, the XML Formatter and JSON Formatter handle pretty-printing, syntax validation, and error highlighting for both. Neither format is going anywhere — knowing when each one is the right tool is the skill worth developing.