JSON vs. YAML: Unterschiede und wann man was nimmt

JSON und YAML lösen dasselbe Problem —— strukturierte Daten als Text darzustellen —— aber sie machen entgegengesetzte Trade-offs. JSON ist auf eindeutiges maschinelles Parsen optimiert, YAML auf menschliches Schreiben. Seit YAML 1.2 ist jedes gültige JSON-Dokument auch gültiges YAML. Diese Anleitung vergleicht ihre Syntax, Typen und Features und erklärt, wann du was nutzen solltest.

Die kurze Antwort

Nutze JSON für Daten, die zwischen Programmen ausgetauscht werden —— API-Antworten, Message-Payloads, alles maschinengeneriert. Nutze YAML für Dateien, die Menschen von Hand schreiben und bearbeiten —— CI-Pipelines, Kubernetes-Manifests, App-Config —— wo Kommentare und Lesbarkeit zählen.

Syntax im Vergleich

Dieselben Daten in beiden Formaten:

# YAML
service: api
replicas: 3
ports:
  - 8080
  - 8443
env:
  LOG_LEVEL: info
  DEBUG: false

// JSON
{
  "service": "api",
  "replicas": 3,
  "ports": [8080, 8443],
  "env": {
    "LOG_LEVEL": "info",
    "DEBUG": false
  }
}

YAML verwendet Einrückung statt geschweifter und eckiger Klammern, lässt die meisten Anführungszeichen weg und erlaubt Kommentare. JSON ist wortreicher, hat aber keinen signifikanten Whitespace, was es deutlich einfacher zuverlässig zu parsen und zu generieren macht.

YAML ist eine Obermenge von JSON

Seit YAML 1.2 (2009) ist YAML eine strikte Obermenge von JSON —— jedes gültige JSON-Dokument ist gültiges YAML, weil YAML die „flow"-Syntax von JSON direkt übernommen hat. Deshalb kannst du JSON in eine YAML-Datei einfügen und es funktioniert. Zur Geschichte siehe YAML 1.2 und JSON-Kompatibilität.

# Das ist gültiges YAML —— gleichzeitig gültiges JSON
{"service": "api", "replicas": 3}

Feature-Vergleich

Typbehandlung: YAMLs scharfe Kanten

YAMLs Eifer, Typen zu inferieren, verursacht Überraschungen, die JSONs explizites Quoting vermeidet:

# Das „Norway problem" —— diese werden in YAML 1.1 Parsern Booleans
countries:
  - NO   # → false (!)
  - SE
  - true # → Boolean, nicht der String "true"

version: 1.20   # → die Zahl 1.2, die hintere Null geht verloren
zip: 01234      # → 668 (als Oktal geparst) in manchen Parsern

JSON hat keine dieser Mehrdeutigkeiten: "NO" ist immer der String NO, und "01234" ist immer dieser String. Wenn ein YAML-Wert ein String sein muss, quotest du ihn explizit.

Wo TOML und JSON5 hineinpassen

Zwei weitere verbreitete „menschenfreundliche" Config-Formate, die in derselben Diskussion auftauchen:

• TOML —— Section/Key-Stil, ausgelegt auf händisch editierte App-Configuration (Cargo, Poetry, Hugo). Strenger als YAML, keine signifikante Einrückung, native typisierte Werte (datetime, integer, float, array, inline table). Am besten, wenn die Daten überwiegend flache Tabellen sind.
• JSON5 —— JSON mit entwicklerfreundlichen Lockerungen: Kommentare, Trailing Commas, ungequotete Keys, Single Quotes, mehrzeilige Strings. Akzeptiert kein Standard-JSON-Parser; du steigst mit einer JSON5-Bibliothek ein (oder einem JSONC-Parser für die Teilmenge Kommentare + Trailing Commas, z. B. tsconfig.json).

Grobe Einordnung: JSON für den Maschinenaustausch, YAML für tief verschachtelte, von Menschen editierte Config, TOML für flache App-/Tool-Config, JSON5/JSONC, wenn du JSON-mit-Kommentaren für Editor-Configs willst, ohne YAMLs Whitespace-Regeln zu übernehmen.

Wann was nutzen

• Nutze JSON für: REST/GraphQL-APIs, Message Queues, Browser-localStorage, package.json, alles, was von Code erzeugt oder konsumiert wird.
• Nutze YAML für: GitHub Actions / GitLab CI, Kubernetes und Docker Compose, Ansible-Playbooks, App-Config, die Menschen bearbeiten und kommentieren wollen.

Ein verbreitetes Muster: Config in YAML schreiben (Lesbarkeit), dann zur Build- oder Ladezeit in JSON konvertieren, damit deine Anwendung nur JSON parst.

Zwischen JSON und YAML konvertieren

# Python —— YAML nach JSON
import yaml, json
data = yaml.safe_load(open('config.yaml'))
print(json.dumps(data, indent=2))

# Kommandozeile mit yq
yq -o=json '.' config.yaml      # YAML → JSON
yq -P '.' config.json           # JSON → YAML

Oder konvertiere sofort im Browser mit fixjsons YAML ⇄ JSON Converter —— YAML einfügen, JSON erhalten (oder umgekehrt), ohne dass Daten an einen Server geschickt werden.

Häufig gestellte Fragen

Ist YAML besser als JSON?

Keines ist „besser" —— sie sind auf unterschiedliche Aufgaben abgestimmt. YAML ist besser für von Menschen editierte Config (Kommentare, Lesbarkeit); JSON ist besser für Maschinen-Datenaustausch (einfaches, schnelles, eindeutiges Parsen).

Ist JSON gültiges YAML?

Ja. Seit YAML 1.2 ist YAML eine strikte Obermenge von JSON, daher ist jedes gültige JSON-Dokument auch gültiges YAML. Umgekehrt gilt das nicht —— die meisten YAML sind kein gültiges JSON.

Warum macht YAML aus „NO" ein false?

YAML inferiert Typen aus ungequoteten Skalaren, und manche Parser lesen NO, yes, on, off als Booleans (das „Norway problem"). Quote den Wert ("NO"), um einen String zu erzwingen. JSON vermeidet das vollständig mit obligatorischen Anführungszeichen.

Soll ich YAML oder JSON für Config-Dateien nutzen?

Nutze YAML, wenn Menschen die Datei bearbeiten und von Kommentaren und mehrzeiligen Strings profitieren; nutze JSON, wenn Tooling sie erzeugt oder konsumiert. Viele Teams schreiben YAML und konvertieren beim Laden zu JSON.

Im Browser konvertieren und validieren

• YAML ⇄ JSON Converter —— in beide Richtungen konvertieren, clientseitig
• YAML-Formatter —— YAML formatieren, neu einrücken und validieren
• Was ist JSON? —— das Format, von dem YAML eine Obermenge ist
• Wie man JSON formatiert —— die konvertierte Ausgabe pretty-printen
• YAML 1.2 und JSON-Kompatibilität —— wie YAML zur JSON-Obermenge wurde