JSON vs YAML vs XML

All three represent structured data as text. JSON is the simplest and strictest, and the default for web APIs. YAML is the most pleasant to write by hand and supports comments, which is why configuration files (Kubernetes, CI pipelines, Ansible) use it, but its implicit typing has traps. XML is the most verbose but has attributes, namespaces, mixed text and markup, and mature schema validation, so it remains the format of documents and long-lived standards (Office files, SVG, RSS, SOAP, sitemaps).

At a glance

The same record in each format:

{
  "name": "web-01",
  "port": 8080,
  "enabled": true,
  "tags": ["prod", "eu"]
}

# Server settings
name: web-01
port: 8080
enabled: true
tags:
  - prod
  - eu

<!-- Server settings -->
<server name="web-01">
  <port>8080</port>
  <enabled>true</enabled>
  <tags>
    <tag>prod</tag>
    <tag>eu</tag>
  </tags>
</server>

These files are 84, 78 and 161 bytes. The JSON and YAML versions parse to identical data; in the XML version 8080 and true are just text, and the writer had to choose whether name is an attribute or a child element.

JSON

JSON has six kinds of value and one way to write each, so parsers in every language agree on what a document means. That predictability is why it won for APIs. The cost is that it is unforgiving to edit by hand: one trailing comma or single-quoted string and the whole file is invalid. Check files with the JSON Validator & Online Debugger.

Choose JSON when programs exchange data: API requests and responses, messages, logs, browser storage, or any file mostly written by software.

YAML

YAML uses indentation instead of brackets and allows comments, multi-line strings and anchors to avoid repetition. It is pleasant to write but easy to get subtly wrong. YAML 1.1 parsers, still common (PyYAML is one), guess types from unquoted values:

Quote values that must stay strings, and validate with the YAML Validator. Never load untrusted YAML with a loader that can construct arbitrary objects; use your library's safe loader.

Choose YAML when people edit the file by hand and comments help: application configuration, deployment manifests, CI workflows.

XML

XML separates markup from text, so it can represent documents where prose and structure mix (<p>Click <b>here</b></p>), not just records. Namespaces let several vocabularies share one file, and XSD can enforce types, ranges and structure before data is accepted. It is verbose, and parsers must be configured carefully: disable external entities and DTD processing for untrusted input to avoid XXE and "billion laughs" attacks.

Choose XML when a standard or partner requires it, when documents mix text and markup, or when you need strict schema validation and namespaces.

Which should you choose?

• Web API or data passed between programs: JSON.
• Configuration that people edit and comment: YAML (quote strings that look like numbers or booleans).
• Documents, mixed content or an established XML standard: XML.
• Converting between them: the JSON to YAML Converter, YAML to JSON Converter, JSON to XML Converter and XML to JSON Converter do it in the browser; expect XML conversions to need a decision about attributes versus elements.

For JSON's syntax rules in detail, see How JSON Works.