JSON vs. YAML: Unterschied und Umwandlung

Veröffentlicht 18. Juli 2026

JSON und YAML sind zwei Arten, dasselbe zu schreiben: strukturierte Daten aus Objekten, Listen, Strings, Zahlen und Booleans. JSON verpackt es in Klammern und Kommas, YAML nutzt Einrückung und Zeilenumbrüche. Da sie identische Strukturen abbilden, lässt sich verlustfrei umwandeln — ein paar Fallen sollte man aber kennen.

Wir haben das selbst gemessen — und dabei unseren eigenen Fehler gefunden. {"service":"api","ports":[80,443],"env":{"DEBUG":"false","RETRIES":3}} durch unseren JSON-zu-YAML-Konverter ergibt:
service: api
ports:
  - 80
  - 443
env:
  DEBUG: 'false'
  RETRIES: 3
DEBUG behält seine Anführungszeichen, RETRIES nicht — und genau darum geht es: In YAML ist ein unquotiertes false ein Boolean, das Entfernen würde den Typ stillschweigend ändern. Beachte: Es sind einfache Anführungszeichen. Unsere eigene Beispielseite schrieb "false" mit doppelten, bis ein Prüfskript den veröffentlichten Text mit der echten Ausgabe des Werkzeugs verglich und die Abweichung meldete. Kleiner Unterschied — aber eine Doku-Seite, die nicht zu ihrem eigenen Werkzeug passt, ist schlimmer als keine Seite.

Dieselben Daten, zwei Stile

JSON:

{ "name": "Yunknow", "tags": ["free", "fast"], "active": true }

YAML:

name: Yunknow
tags:
  - free
  - fast
active: true

Dieselben Daten, andere Kleidung. YAML lässt die Satzzeichen weg und setzt auf Einrückung — genau deshalb lieben Konfigurationsdateien es.

Verschachtelung ist die sichtbarste Differenz zwischen beiden Notationen. Dieses JSON — eine Liste und ein verschachteltes Objekt — durch unseren JSON-↔-YAML-Konverter:

list:
  - 1
  - 2
deep:
  k: 'yes'

Klammern wurden zu Einrückung, Listenelemente zu --Einträgen. An den Daten hat sich nichts geändert; die Trennzeichen sind in den Leerraum gewandert. Das ist gleichzeitig der Grund, warum YAML leichter zu lesen und leichter zu zerbrechen ist — ein falsch gesetztes Leerzeichen ist eine strukturelle Änderung.

Wann welches

JSON — APIs, package.json, alles, was ein Programm automatisch liest oder schreibt. Streng, eindeutig, universell unterstützt.
YAML — Konfiguration, die du von Hand bearbeitest: Docker Compose, Kubernetes, GitHub Actions, CI-Pipelines. Leichter lesbar, mit Kommentaren.

Ein üblicher Ablauf: Konfiguration in YAML schreiben und von Tools als JSON einlesen lassen.

Dieser Unterschied entscheidet die Wahl weit öfter als die Syntaxvorliebe. JSON hat genau sechs Werttypen und keine Typinferenz, v: 'true' port: '8080' kann dort also gar nicht passieren: Ein quotierter String bleibt String, es gibt keine Regel, vor der man ihn retten müsste. YAML inferiert — genau das macht es angenehm für handgeschriebene Konfiguration und riskant für maschinell erzeugte Daten.

Stolperfallen

Einrückung ist in YAML bedeutsam. Tabs und Leerzeichen zu mischen oder die Tiefe zu verfehlen ändert die Bedeutung oder bricht das Parsen. Immer mit Leerzeichen einrücken.
Kommentare verschwinden nach JSON. JSON kennt keine Kommentarsyntax, daher gehen # Notiz-Zeilen bei YAML → JSON verloren. Das ist erwartet, kein Fehler.
Das „Norwegen-Problem”. In älterem YAML werden unquotierte no, yes, on, off zu Booleans — der Ländercode NO kann so zu false werden. Strings, die wie Booleans aussehen, in Anführungszeichen setzen.
Anker werden aufgelöst. Die Wiederverwendung per &anchor/*ref in YAML wird bei der Umwandlung in JSON zu flachen Daten aufgelöst.

Und hier der Fallstrick, der echte Zeit kostet. Unser Konverter zeigt ihn als Anführungszeichen, die niemand verlangt hat:

name: x
'on': true
'n': null

on und n kamen quotiert zurück. In YAML 1.1 sind die bloßen Wörter on, off, y, n, yes und no Booleans, ein unquotierter Schlüssel on würde also als true gelesen. Der Spiegelfall ist ein Wert, der String bleiben muss:

v: 'true'
port: '8080'

Beide behielten ihre Anführungszeichen, denn ohne sie würde ein String zum Boolean und eine Portnummer zum Integer. Das ist das berühmte „Norway-Problem” — NO als false gelesen — und eine Eigenschaft von YAML selbst, nicht eines einzelnen Konverters.

Funktionsvergleich

Merkmal	JSON	YAML
Kommentare	Nein	Ja (`#`)
Nachgestellte Kommas	Nicht erlaubt	Nicht relevant
Lesbarkeit	Gut	Bei tiefer Verschachtelung besser
Parsing-Geschwindigkeit	Schneller	Langsamer
Mehrzeilige Strings	Nur escaptes `\n`	Block-Skalare
Mehrere Dokumente pro Datei	Nein	Ja (`---`-Trenner)

Ein oft übersehenes YAML-Feature sind Block-Skalare für langen Text — ein Literal-Block behält Zeilenumbrüche, ein gefalteter Block fügt sie zu einer Zeile zusammen:

description: |
  Zeile eins bleibt eine Zeile.
  Zeile zwei bleibt eine Zeile.
summary: >
  Das erstreckt sich über
  mehrere Quellzeilen,
  wird aber eine Zeile.

Häufige Fragen

Ist YAML eine Obermenge von JSON? Praktisch ja. Seit YAML 1.2 ist jedes gültige JSON auch gültiges YAML, ein YAML-Parser liest JSON also direkt. Umgekehrt gilt das nicht — JSON versteht die Einrückungssyntax von YAML nicht.

Was sollte eine API zurückgeben? Fast immer JSON — schneller zu parsen, eindeutig und überall unterstützt. YAML bleibt für Dateien, die Menschen von Hand bearbeiten.

Wo sind meine Kommentare nach der Umwandlung? Sie entfallen, weil JSON keine Kommentarsyntax kennt. Willst du Notizen behalten, füge stattdessen einen echten Schlüssel wie "_comment" hinzu. Einen tieferen Blick auf das Format gibt Was ist JSON.

Akzeptieren Tools beide Formate? Viele CI- und Container-Werkzeuge lesen wahlweise YAML oder JSON derselben Struktur. Du kannst also bequem in YAML schreiben und bei Bedarf nach JSON exportieren, ohne die Bedeutung der Daten zu ändern.

Sicher umwandeln, im Browser

Der JSON-⇄-YAML-Konverter wandelt eins ins andere um und prüft dabei die Syntax — bei einem Fehler zeigt er die genaue Stelle. Er läuft komplett im Browser, sodass selbst private Konfiguration dein Gerät nie verlässt.