XML versus JSON

The XML Infoset carries ordered children, attributes, mixed content, namespaces, comments, processing instructions and a document type declaration. RFC 8259 gives objects, arrays, strings, numbers, booleans and null. The second set is a strict subset, so every generic XML to JSON conversion discards or invents something.

• Order. An RFC 8259 object is an unordered collection of pairs. XML children are ordered, and in a document format that order is the content.
• Duplicate names. RFC 8259 section 4 says names SHOULD be unique, and where they are not "the behavior of software that receives such an object is unpredictable". Repeated sibling elements are ordinary XML.
• Numbers. XML content is text, so 007 and 1.10 survive. JSON has one numeric type, and section 6 warns interoperability holds only within IEEE 754 binary64. A 19-digit identifier does not round-trip.
• Attributes. XML has two places to put a scalar, JSON has one. Attribute or child element is an argument you never have in JSON.
• Comments. XML has them. JSON has no production for one, which is why JSON5 and JSONC exist and why neither is JSON.
• Encoding. RFC 8259 section 8.1 requires UTF-8 outside a closed ecosystem. XML declares its own, which is more flexible and more to get wrong.

Michael Kay put it precisely in Schema-Aware Conversion of XML to JSON: a generic converter "is guessing what the semantics of the object model are that lie behind the lexical XML, and it is guessing wrong". The everyday version is the singleton problem. XML has no cardinality without a schema, so one item element becomes an object and two become an array, and code that maps over the result breaks on single-item responses. fast-xml-parser hands you an isArray callback; xml2js wraps everything in arrays instead.

A paragraph of prose with emphasis inside it has three ordered children: text, an element, more text. XML expresses that natively. JSON objects cannot: members are unordered and a key holds one value.

{
  "p": {
    "b": "is important",
    "#text": "Some text ."
  }
}

<p>Some text <b>is important</b>.</p>

The text fragments have been concatenated and their position relative to the b element is gone. This is not one library misbehaving: the author of BadgerFish lists the same defect in his own specification. Only a positional encoding such as JsonML survives it, at the cost of arrays like ["p", "Some text ", ["b", "is important"], "."].

This is why every serious document format is XML and stays XML: DocBook, DITA, JATS, TEI, OOXML, ODF, EPUB, SVG. If your payload is a record, mixed content costs you nothing. If it is a document, JSON cannot hold it without a markup convention inside strings, which is how you end up parsing HTML with regular expressions.

Under Namespaces in XML 1.0 an element name is a pair, a namespace URI and a local name, and the prefix is a document-local label with no significance. Two vocabularies can be mixed in one document with no coordination between their authors, which is what a SOAP envelope and an XHTML page with embedded SVG both rely on.

JSON has nothing equivalent. Keys are strings in one flat space, so merging two vocabularies means prefixing keys by hand, nesting them under a wrapper, or hoping they never collide. JSON-LD adds an @context mapping terms to IRIs, but it is an opt-in layer for linked data rather than a guarantee of the format.

The honest counterweight is that namespaces cost XML users time every week. The default namespace does not apply to unprefixed attributes, and XPath 1.0 has no notion of one at all, so an expression copied from a document matches nothing until you bind a prefix. JSON developers pay none of this because they gave up the capability.

JSON Schema is genuinely good now, and any comparison written before about 2019 understates it. Draft 2020-12 has composition, references, conditionals and annotation vocabularies, and OpenAPI 3.1 aligned with it, so an OpenAPI description carries a real schema rather than a shape suggestion.

Two things reliably surprise people. In 2020-12 the format keyword is an annotation by default, not an assertion: unless the validator opts into the format-assertion vocabulary, "format": "email" reports nothing on a value that is not an email address. And XSD 1.1 assertions, the feature that would answer JSON Schema conditionals, are implemented by Xerces-J and Saxon-EE and almost nothing else, so you are really comparing 2020-12 against XSD 1.0.

The remaining structural advantage of XSD is that validation happens before your code runs. A SOAP stack rejects a non-conforming message at the boundary; a JSON Schema is a file someone has to remember to apply. That is a process difference rather than a language one, and it is why regulated formats specify XSD.

XML is more verbose, mostly because a closing tag repeats the element name, and over the wire that is the cheapest kind of redundancy there is. DEFLATE, behind gzip and ancestral to brotli, replaces a repeated byte sequence with a reference to its earlier occurrence, and a closing tag is a verbatim repeat of a string from a few bytes ago. Compressed, the two formats land far closer than raw byte counts suggest.

What compression does not remove is the parse cost. Building a DOM with namespace resolution and attribute nodes is more work than building plain objects, and JSON.parse is a native, heavily optimised path with no XML equivalent. If you are choosing on performance, that is the argument, not bytes on the wire.

Missing from the JSON side: anything where a human edits a long document, or a regulator specifies the message. Missing from the XML side: anything new that is browser-facing. FHIR is the clearest split, publishing both serialisations of the same resources.

• Choose JSON for a new API consumed by browsers or mobile clients, described with JSON Schema through OpenAPI 3.1.
• Choose XML when the payload is a document, when a counterparty publishes an XSD, or when you must sign part of a message rather than all of it.
• Converting between them, settle the singleton-versus-array rule and the coercion rule first. Those two cause most of the bugs.