JSON vs. YAML: Unterschiede und wann du welches Format nutzt

JSON und YAML beschreiben dieselben Daten: Objekte, Listen, Texte, Zahlen, Wahrheitswerte und null. Der Unterschied liegt in der Schreibweise. JSON ist streng und eindeutig und eignet sich für den Datenaustausch zwischen Programmen, etwa bei APIs. YAML ist für Menschen gemacht, erlaubt Kommentare und wird deshalb für Konfigurationsdateien genutzt, etwa bei Kubernetes, GitHub Actions und Docker Compose.

Wenn du ein Dokument von einem Format ins andere bringen willst, nimm den JSON-zu-YAML-Konverter oder den YAML-zu-JSON-Konverter. Beide laufen komplett lokal in deinem Browser. formatierer.de sendet nichts an einen Server.

Dasselbe Beispiel in beiden Formaten

Zuerst JSON:

{
  "name": "shop-api",
  "port": 8080,
  "debug": false,
  "tags": ["web", "api"],
  "database": {
    "host": "db.local",
    "timeout": 2.5
  }
}

Und dieselben Daten in YAML:

# Konfiguration der Shop-API
name: shop-api
port: 8080
debug: false
tags:
  - web
  - api
database:
  host: db.local
  timeout: 2.5

YAML braucht weder geschweifte Klammern noch Anführungszeichen um Schlüssel und einfache Texte. Die Struktur ergibt sich aus der Einrückung. Und die erste Zeile zeigt etwas, das JSON nicht kann: einen Kommentar.

Vergleich auf einen Blick

YAML ist (fast) eine Obermenge von JSON

Seit YAML 1.2 ist das Format so definiert, dass fast jedes gültige JSON-Dokument auch gültiges YAML ist. Das beruht darauf, dass YAML die JSON-Schreibweise mit {} und [] als „Flow-Stil“ kennt. Du kannst JSON also oft unverändert an einen YAML-Parser geben.

Zwei Einschränkungen:

• Doppelte Schlüssel sind in YAML laut Spezifikation nicht erlaubt. JSON-Parser behalten dagegen meist stillschweigend den letzten Wert. Je nach YAML-Bibliothek gibt es einen Fehler oder ebenfalls nur den letzten Wert.
• Nicht jede Bibliothek folgt YAML 1.2. Verbreitete Parser wie PyYAML arbeiten noch nach YAML 1.1, das sich in Details unterscheidet. Für JSON-Dokumente fällt das selten auf, bei handgeschriebenem YAML aber schon (siehe nächster Abschnitt).

Umgekehrt gilt das nicht: Ein YAML-Dokument mit Kommentaren, Ankern oder Einrückungsstruktur ist kein gültiges JSON.

Typische Stolperfallen in YAML

Einrückung. Nur Leerzeichen, keine Tabs. Ein Leerzeichen zu viel oder zu wenig verändert die Struktur, oft ohne Fehlermeldung:

database:
  host: db.local
 timeout: 2.5   # falsch eingerückt → Fehler oder anderes Ergebnis

Implizite Typen. YAML entscheidet selbst, ob ein ungequoteter Wert ein Text, eine Zahl oder ein Wahrheitswert ist:

version: 1.10      # Zahl 1.1, nicht der Text "1.10"
plz: 01067         # je nach Parser Oktalzahl oder Zahl ohne führende Null
land: NO           # in YAML 1.1 der Wahrheitswert false

Das berühmteste Beispiel ist das „Norwegen-Problem“: Der Ländercode NO wird in YAML 1.1 als false gelesen, ebenso no, off und andere Wörter. YAML 1.2 kennt in seinem Standard-Schema nur noch true und false. Details im Ratgeber YAML-Norway-Problem. Im Zweifel setzt du Werte, die Texte bleiben sollen, in Anführungszeichen: land: "NO".

Doppelpunkt und # in Texten. Ein Wert wie Hinweis: wichtig oder a #b muss in Anführungszeichen stehen, sonst wird er als Struktur oder Kommentar gelesen.

JSON hat diese Probleme nicht: Ein Text steht immer in Anführungszeichen, eine Zahl nie. Dafür sind die Fehler dort sofort sichtbar, zum Beispiel ein Komma am Ende. Das hilft dir bei der Fehlersuche im JSON-Formatierer.

Anker und Aliase

YAML erlaubt es, einen Block einmal zu definieren und an anderer Stelle wiederzuverwenden:

standard: &standard
  restart: always
  retries: 3

web:
  <<: *standard
  image: nginx

worker:
  <<: *standard
  image: my-worker

&standard benennt den Block, *standard verweist darauf, und << führt die Einträge in das aktuelle Objekt zusammen. Den Merge-Key << gibt es nicht im Kern von YAML 1.2, viele Bibliotheken unterstützen ihn aber. JSON hat nichts Vergleichbares, dort musst du den Block wiederholen. Der YAML-zu-JSON-Konverter löst Anker, Aliase und Merge-Keys auf und gibt dir das ausgeschriebene JSON.

Wann welches Format?

• APIs und Datenaustausch: JSON. Es ist eindeutig, schnell zu parsen und in jeder Sprache und jedem Browser eingebaut (JSON.parse(), json.loads()). Webservices, package.json und die meisten Logformate nutzen es.
• Konfigurationen, die Menschen pflegen: YAML. Kommentare, wenig Rauschen und Wiederverwendung per Anker machen Dateien wie Kubernetes-Manifeste, GitHub-Actions-Workflows und docker-compose.yml gut wartbar.
• Konfiguration, die vor allem Programme schreiben: JSON. Maschinell erzeugte Dateien sind in JSON robuster, weil es nur eine Schreibweise gibt.
• Du brauchst Kommentare, willst aber bei JSON bleiben: Schau in den Ratgeber Kommentare in JSON (JSONC, JSON5).
• Beides im Einsatz: Das ist üblich. Werkzeuge wie Kubernetes akzeptieren beide Formate, intern arbeiten sie mit derselben Datenstruktur. Du kannst jederzeit konvertieren, ohne Daten zu verlieren, solange du in YAML nur Funktionen nutzt, die JSON kennt. Kommentare gehen beim Umwandeln nach JSON verloren.

Kurz gesagt

• JSON und YAML beschreiben dieselben Datentypen. Sie unterscheiden sich in Schreibweise und Strenge.
• JSON für APIs und Datenaustausch, YAML für Konfigurationsdateien, die Menschen lesen und kommentieren.
• Fast jedes gültige JSON ist gültiges YAML 1.2, aber nicht umgekehrt. Doppelte Schlüssel und YAML-1.1-Parser sind die Ausnahmen.
• Bei YAML: nur Leerzeichen einrücken und Werte in Anführungszeichen setzen, die Text bleiben sollen ("NO", "01067").
• Konvertieren geht in beide Richtungen: JSON zu YAML und YAML zu JSON.

Weiterlesen: Was ist JSON?, Was ist YAML?, YAML-Norway-Problem, Kommentare in JSON.