Is JSON a subset of XML?

No. JSON is objects, arrays, strings, numbers, booleans and null. XML is a tree of named elements with attributes, text, comments, CDATA and namespaces. You can convert between them, but the mapping is a convention, not an identity.

When should I pick XML over JSON?

When the ecosystem already speaks XML: SOAP, SAML, UBL invoices, Maven POMs, Android manifests, RSS/Atom. Those formats have schemas, namespaces and mixed content that JSON does not model cleanly.

Is every JSON document valid YAML?

Yes. YAML 1.2's data model is a superset of JSON's, so valid JSON parses as YAML. The reverse is false: anchors, comments and multi-line scalars have no JSON form.

Why do XML attributes become @_ keys in JSON?

JSON has no attribute slot. The de-facto interchange used by fast-xml-parser prefixes attributes with @_, so becomes {"@_id":"bk101"}. A round trip can drop comments and the XML declaration.

Which format is fastest to parse?

JSON, by a wide margin. YAML parsers are slower and do implicit typing. XML parsers are mature but pay for namespaces, entities and mixed content. Pick the format the other side already uses.

Can I convert XML to JSON in the browser?

Yes. The XML → JSON converter and the XML Formatter both run in this tab. Comments, CDATA wrappers and the XML declaration drop because JSON has no syntax for them.

JSON vs YAML vs XML | LocalFirstTools

JSON, YAML and XML all describe trees, but they are not interchangeable spellings of the same idea. JSON is the interchange format of the web. YAML is JSON's superset for humans editing configuration. XML is a document format with attributes, namespaces and mixed content, still required by SOAP, SAML, invoices and a long tail of enterprise schemas. Use the format the other system already speaks, then convert locally with JSON ↔ XML, JSON ↔ YAML or the XML Formatter.

The same record in all three

JSON:
{"book":{"id":"bk101","title":"SICP","price":39.95,"inStock":true}}

YAML:
book:
  id: bk101
  title: SICP
  price: 39.95
  inStock: true

XML:
<book id="bk101">
  <title>SICP</title>
  <price>39.95</price>
  <inStock>true</inStock>
</book>

JSON puts id in the object. XML can put it on the element as an attribute. YAML looks like JSON without the braces until implicit typing bites you: unquoted no becomes false, and 007 becomes 7. Quote anything that must stay a string. Converting YAML to JSON is a quick audit for those surprises; see JSON vs YAML vs CSV when the third format is a table rather than a document.

Data model, not syntax

JSON's model is tiny: object, array, string, number, boolean, null. There are no comments in RFC 8259, no attributes, and no distinction between “element” and “text”. That is why JSON parsers are fast and why two serializers that agree on the model produce documents you can compare structurally.

YAML 1.2 can represent every JSON value and then some: comments, anchors and aliases, multi-line scalars, and tags. The cost is implicit typing and a parser that is orders of magnitude slower than JSON. YAML belongs in files humans edit (Kubernetes manifests, GitHub Actions, app config), not on the hot path of an API.

XML's model is a tree of named elements. Attributes are a second slot on each element. Text and child elements can mix in the same parent (mixed content: Use this.). Namespaces let two vocabularies share a document. Comments, processing instructions, CDATA and a DOCTYPE exist. None of those have a JSON equivalent, so XML → JSON is a lossy convention, not a round-trip identity. The convention this site uses is the common one: attributes become keys prefixed with @_, repeated sibling tags become arrays, text becomes a value. Try it on XML to JSON.

When to use each

JSON for APIs, logs, browser payloads, and anything a program exchanges. Validate and pretty-print with the JSON Formatter. Compact with the JSON Minifier.
YAML for configuration humans edit. Convert to JSON when you need to see what the implicit types actually became, then convert back.
XML when the other side already requires it: SOAP, SAML, UBL/Peppol, Maven, Android, RSS/Atom, Office custom XML. Format and check well-formedness with the XML Formatter. If a gateway says “not well-formed”, start with how to fix that error.

Do not invent an XML API for a new service in 2026 unless you are extending an XML-only ecosystem. Do not store a CRM export as XML if CSV or JSON objects will do: attributes and mixed content are overhead you will pay on every row.

Conversion is a convention

<book id="bk101"><title>SICP</title></book> becomes roughly:

{
  "book": {
    "@_id": "bk101",
    "title": "SICP"
  }
}

A single child cannot be told apart from a one-item list. Comments and the XML declaration disappear. CDATA becomes ordinary text. Going back with JSON → XML rebuilds a document that is equivalent for data, not byte-identical. If you need a byte-stable XML file, keep the XML and only convert a copy.

YAML → JSON is closer to lossless for data (anchors expand into copies) but drops comments. JSON → YAML is usually tidy. CSV is a different shape entirely: rows and columns, no nesting. Open a spreadsheet export in the CSV Viewer before you decide it should become JSON objects.

A practical decision order

1. If an existing contract names the format, use that format. 2. If humans will edit the file weekly, YAML (or JSONC in editors that allow comments). 3. If programs exchange it over HTTP, JSON. 4. If the document has mixed content, attributes that are not just fields, or a mandated schema, XML. 5. If it is a table, CSV, then convert.

All of the conversions on this site run in your browser. Production API responses, SAML assertions and payroll CSVs stay on the device.

Namespaces, schemas and why XML is still here

XML survived because it can name things in more than one vocabulary at once. A SAML assertion embeds XML Signature and XML Encryption elements under different namespace URIs. A UBL invoice mixes common aggregate components with country-specific extensions. JSON can fake that with nested objects, but it has no standard equivalent of xmlns and no widely deployed schema language with the same reach as XSD. JSON Schema exists and is useful; it is not what a Peppol access point validates against.

That is also why “just convert everything to JSON” fails as a migration plan. You can convert a SOAP body for a test fixture. You cannot drop XML from a network that already speaks it. Keep a well-formedness check in the loop: validate, then convert a copy. If the JSON looks “too nested”, the XML used wrapper elements for lists. That is faithful, not a bug.

Comments are a three-way split. JSON has none (RFC 8259). YAML has # to end-of-line. XML has . If the comments are the point of the file (a hand-edited config), YAML wins. If you need them after a round trip through an API, do not convert; the API will drop them. CDATA in XML is a quoting device, not a type: <![CDATA[use for emphasis]]> is still text.

Numbers and booleans are another split. JSON has real types. YAML guesses. XML is text until a schema says otherwise: <price>39.95</price> is a string to a well-formedness parser. After XML → JSON, a converter may coerce that to a number or leave it as a string. Check the JSON before you treat it as typed data, the same way you would after CSV → JSON.

If you are choosing for a greenfield service: JSON on the wire, YAML in the repo, CSV for exports, XML only when a counterpart already requires it. Format each one locally before you commit or send it.

JSON vs YAML vs XML: differences and when to use each