This article compares the two formats as a working developer would: same payload, different syntax, then the properties that actually change parsing, validation, and maintenance.

The distinction that matters

XML is a markup language. You invent tags, attach attributes, nest mixed content, and optionally bind the document to a schema and namespaces. The unit of thought is a document tree.

JSON is a data-interchange format. You describe objects and arrays with a small set of native types: string, number, boolean, null, object, array. The unit of thought is a value.

That is why JSON maps so cleanly onto JavaScript, Python dicts, and Go structs, and why XML still wins when the payload is a document rather than a record.

The same order, twice

Here is a tiny order payload in both formats. The data is identical; the modelling is not.

<?xml version="1.0" encoding="UTF-8"?>
<order id="ord-2041" currency="USD">
  <customer>
    <name>Asha Rao</name>
    <email>asha@example.com</email>
  </customer>
  <items>
    <item sku="KB-87">
      <title>Mechanical keyboard</title>
      <qty>2</qty>
      <price>129.00</price>
    </item>
  </items>
  <shipped>true</shipped>
</order>

{
  "id": "ord-2041",
  "currency": "USD",
  "customer": {
    "name": "Asha Rao",
    "email": "asha@example.com"
  },
  "items": [
    {
      "sku": "KB-87",
      "title": "Mechanical keyboard",
      "qty": 2,
      "price": 129.0
    }
  ],
  "shipped": true
}

Three differences show up immediately:

1. Attributes vs keys. XML can put id and currency on the element. JSON has no attributes, so those become sibling fields. If you convert XML to JSON naively, you either drop the attributes or invent a convention such as @id.
2. Types. In JSON, qty is a number and shipped is a boolean. In XML, both are text unless an XSD (or your parser) says otherwise.
3. Lists. JSON has a first-class array. XML represents a list by repeating <item> under a parent. One child looks like a scalar; two children look like a list. That ambiguity is a common source of brittle converters.

Count the characters if you like. Closing tags make the XML version larger. Gzip narrows the gap on the wire, but uncompressed size still matters for logs, mobile clients, and anything you parse on every request.

What each format is good at

JSON is the right default for REST and most GraphQL-adjacent payloads, browser clients, mobile apps, and document stores such as MongoDB. JSON.parse is native in every browser. The grammar is small, so parsers are fast and error messages are local. Configuration files (package.json, many cloud manifests) follow the same shape.

XML is the right default when you need any of: mixed content (text interleaved with markup), attributes as metadata, namespaces across vocabularies, comments in the payload, or strict validation against XSD/DTD. XPath, XSLT, and XQuery remain the most mature query and transform stack for tree-shaped documents. If a bank, hospital, or government partner hands you an ISO 20022 or HL7 schema, you are not choosing JSON for taste.

A compact comparison:

• Mental model: XML = document tree; JSON = objects and arrays
• Native types: XML = text unless a schema adds them; JSON = string, number, boolean, null, object, array
• Metadata: XML attributes; JSON extra keys
• Comments: XML yes; JSON not in RFC 8259
• Namespaces: XML built-in; JSON naming conventions only
• Schema: XML XSD/DTD; JSON Schema (external)
• Typical home: XML documents/SOAP/SVG/Office; JSON REST/web/mobile/configs

Parsing, security, and cost

JSON usually parses faster in JavaScript runtimes because the syntax maps onto native objects. XML parsers must match tags, resolve namespaces, and often build a DOM. At high QPS that difference is real; for a nightly batch job it is noise.

Security is not "JSON is safer" or "XML is safer." It is parser configuration. Misconfigured XML parsers can resolve external entities (XXE) and read local files. Careless JSON handling — eval instead of JSON.parse, or merging untrusted objects into prototypes — opens a different class of bugs. Validate input. Disable features you do not need. Do not treat a format choice as a security control.

Bandwidth follows size. JSON is typically 30–50% smaller for the same record-shaped data. After gzip or Brotli, repetitive XML tags compress well, so the transferred bytes converge. If you are paying per gigabyte on mobile or IoT, measure both compressed and uncompressed.

A decision rule you can reuse

Ask one question: am I exchanging documents, or exchanging data?

• Documents with mixed content, metadata, namespaces, or a mandated schema → XML.
• APIs, apps, and stores where speed and native types matter → JSON.
• New public REST API with no compliance constraint → JSON, without a debate.
• Integration with an existing SOAP, HL7, or Office pipeline → XML, because the spec already decided.

The common beginner mistake is treating the formats as interchangeable serialisers. They are not. Converting XML to JSON is lossy unless you explicitly preserve attributes, comments, processing instructions, and mixed content. If you must bridge both worlds, pick a mapping convention (@ for attributes, #text for element text) and keep it consistent.

For a full side-by-side of syntax, tooling, misconceptions, and when each format is cheaper long-term, see the difference between XML and JSON on Nex Virox. It is the comparison table this article is distilled from.

In 2026 you will still ship both. Choose the one whose model matches the payload, then stop arguing about which one is "modern."