JSON vs. YAML

JSON ist das Austauschformat: streng, ohne Kommentare und von jeder API und jedem Parser verstanden. YAML ist das Konfigurationsformat für Menschen: per Einrückung gegliedert, kommentarfreundlich und von Hand tippbar. Nehmen Sie JSON für Programme, die mit Programmen reden, und YAML für Menschen, die für Programme schreiben – und konvertieren Sie in beide Richtungen verlustfrei.

Nur lokal

Die beiden Formate werden oft als Rivalen vorgestellt, was die nützliche Wahrheit verschüttet: Sie lösen verschiedene Probleme, und die meisten echten Projekte nutzen beide. JSON hat den Datenaustausch gewonnen, weil seine Grammatik auf eine Indexkarte passt und weil eine Payload, die ein Dienst ausgibt, ein anderer ohne gemeinsame Konfiguration verarbeiten kann. YAML hat die Konfiguration gewonnen, weil die Menschen, die sie bearbeiten, Menschen in einem Texteditor sind – und Menschen wollen Kommentare, lesbare Listen und die Freiheit, Anführungszeichen weglassen zu dürfen.

Der Preis dieser Menschenfreundlichkeit ist eine Spezifikation, die YAMLs eigene Autoren als kompliziert beschreiben: Einrückung trägt Bedeutung, der Typ eines nackten Skalars wird abgeleitet (und der klassische Fehlschlag ist ein Wert wie `no`, der lautlos zu boolean false wird), und eine Datei kann parsen und dabei etwas bedeuten, das ihr Autor nie beabsichtigt hat. JSONs Strenge ist genau das, was es langweilig macht – eine Zahl ist eine Zahl, ein String ist ein String, und kein Editor kann Ihre Datei in ein anderes Dokument umformatieren.

Der Vergleich unten bleibt auf der Ebene, auf der die Kompromisse tatsächlich zubeißen: Syntaxregeln, Typverhalten, Kommentare, Größe und das Tooling, das jedes Format voraussetzt. Wenn Sie zwischen beiden wechseln müssen, gibt es für beide Richtungen ehrliche Konverter auf dieser Site – und wie alles hier laufen sie vollständig in Ihrem Browser.

Konfiguration für die Durchsicht in einer Tabellenkalkulation zu tabellarisieren ist ein üblicher Schritt, und der YAML-zu-CSV-Konverter erledigt das, ohne den Tab zu verlassen.

Brauchen Sie genau die Konvertierung, die diese Seite vergleicht? Der YAML-zu-JSON-Konverter durchläuft den Zyklus aus Parsen und Erzeugen in Ihrem Browser, ohne Upload.

Syntax: Zeichensetzung versus Einrückung

JSONs Grammatik nutzt sechs strukturelle Zeichen – eckige und geschweifte Klammern, Doppelpunkt und Komma –, daher ist die Verschachtelung eines Dokuments an seiner Zeichensetzung ablesbar, und ein Linter kann auf das exakte fehlerhafte Zeichen zeigen. YAML gibt sein Zeichensetzungsbudget stattdessen für Lesbarkeit aus: Verschachtelung ist Einrückung, Listen sind Striche, und Schlüssel/Wert-Paare brauchen keinen weiteren Trenner als Doppelpunkt und Leerzeichen. Das Ergebnis: Ein fünfzeiliges JSON-Dokument wird zu zwei Zeilen YAML, und ein tief verschachteltes wird dramatisch kürzer – zum Preis einer ganzen Fehlerklasse, die JSON nicht hat: die falsche Anzahl von Leerzeichen, die manche Parser auf einer Zeile melden, die gar nicht in der Nähe Ihres Fehlers liegt.

Aspekt	JSON	YAML
Gliederung	Geschweifte und eckige Klammern	Einrückung (nur Leerzeichen)
Kommentare	Keine – per Design entfernt	# bis zum Zeilenende
Anführungszeichen	Bei jedem String erforderlich	Optional für die meisten Skalare
Mehrzeilige Strings	Nur \n-Escapes	Block-Skalare (\| und >)
Anker / Wiederverwendung	Keine	Anker & und Aliase *
Grammatikgröße	Passt auf eine Seite (RFC 8259)	Mehrstufig, berüchtigt komplex

Typen: streng versus abgeleitet

Jeder JSON-Wert deklariert sich selbst: Strings tragen Anführungszeichen, Zahlen sind nackt, Booleans sind exakt true und false. YAML leitet ab. Ein nacktes yes, no, on, off, true oder false ist ein Boolean; ein nacktes 2026-09-19 ist ein Datum; und ein Wert wie 1.20 kann je nach Reader lautlos zur Zahl 1.2 werden. Der Fehlschlag hat in der Community einen Namen – das Norwegen-Problem, nach Ländercodes wie NO, die zu boolean false werden –, und es ist das mit Abstand stärkste Argument, in YAML defensiv zu quoten, selbst wenn der Parser es nicht verlangt.

Die Kehrseite ist Absicht: YAML will Konfigurationsdateien, in denen 8080 ohne Zeremoniell als Portnummer gelesen wird. JSON will Austausch, wo sich Ausgeber und Konsument über jedes Byte einig sein müssen und Ableitung ein Bug ist. Jedes Format optimiert für den Leser, den es erwartet.

Größe, Performance und Tooling

YAML ist meist die kürzere Datei und das langsamere Parsen: Einrückungsscan, mehrzeilige Block-Skalare und Anker-Auflösung kosten alle mehr als JSONs Ein-Durchlauf-Grammatik. Für Konfiguration, die einmal beim Start gelesen wird, ist das irrelevant; für ein Übertragungsformat, das Millionen Male pro Tag gestreamt wird, ist es genau der Grund, warum YAML JSON nie von der Leitung verdrängt hat. Tooling ist die andere Asymmetrie – jede Sprache liefert einen JSON-Parser in ihrer Standardbibliothek, während YAML-Parser Drittanbieter-Software mit echten Unterschieden darin sind, was sie akzeptieren; deshalb dokumentiert dieser Konverter seine unterstützte Untermenge, statt die ganze Spezifikation zu versprechen.

Payload-Größe: YAML gewinnt bei handgeschriebenen Dateien; JSON mit Minifizierung gewinnt oft auf der Leitung, weil sich seine Quoting-Regeln berechenbar komprimieren lassen.
Fehlermeldungen: JSON-Parser zeigen auf das fehlerhafte Zeichen; YAML-Parser zeigen auf die Zeile, in der die Einrückung aufgehört hat zu passen.
Interoperabilität: JSON ist überall der Standard – Log-Pipelines, HTTP-APIs, Browser-Speicher. YAML ist der Standard in Kubernetes, CI-Pipelines und Ansible.
Round-Trips: JSON→YAML→JSON ist verlustfrei mit einem konformen Paar. YAML→JSON kann verlustbehaftet sein, sobald die Datei Features nutzte, die JSON fehlen – Anker, mehrere Dokumente oder Nicht-String-Schlüssel.

Wann sich welches eignet

Die Entscheidung geht selten um Vorlieben und meist um den Leser. Nehmen Sie JSON, wenn ein Programm das Dokument erzeugt und ein anderes es verarbeitet: API-Payloads, strukturierte Logs, gespeicherte Zustände, alles, was eine Vertrauensgrenze überquert. Nehmen Sie YAML, wenn ein Mensch das Dokument schreibt und pflegt: CI-Pipelines, Kubernetes-Manifeste, docker-compose-Dateien, jede Konfiguration, bei der ein Prüfer einen Diff lesen und verstehen muss, ohne Zeichensetzung zu dekodieren.

Und die Empfehlung kippt sauber: Wenn Sie sich dabei ertappen, JSON von Hand mit fünfzehn Verschachtelungsebenen zu formatieren, will diese Datei höchstwahrscheinlich YAML sein. Wenn Sie sich dabei ertappen, zur Laufzeit innerhalb eines Dienstes YAML zu parsen, will diese Datei höchstwahrscheinlich JSON sein. Die unten verlinkten Konverter machen den Wechsel zu einem Ein-Klick-Schritt statt einem Migrationsprojekt.

Häufig gestellte Fragen

Ist YAML eine Obermenge von JSON?

YAML 1.2 hat ausdrücklich die meisten JSON-Dokumente zu gültigem YAML erklärt – eine JSON-Datei mit intakten geschweiften Klammern parst meist unverändert als YAML. Umgekehrt gilt das nie: Kommentare, Anker, nackte Schlüssel und mehrzeilige Strings haben keine JSON-Repräsentation. Der Migrationsweg ist also von vornherein einseitig, und Tools, die volle YAML→JSON-Treue behaupten, wählen still eine Untermenge.

Welches Format lässt sich schneller parsen?

JSON, mit deutlichem und konstantem Abstand. Seine Grammatik ist ein Durchlauf ohne Einrückungszustand; YAML-Scanner verfolgen Spaltenkontext, lösen Block-Skalare auf und expandieren Anker. Für Konfiguration beim Start sind der Unterschied Millisekunden und irrelevant; für Traffic mit hohem Volumen zwischen Maschinen ist es einer der zwei Gründe, warum JSON die Leitung besitzt (der andere ist die universelle Unterstützung in Standardbibliotheken).

Warum nutzen CI-Systeme und Kubernetes YAML statt JSON?

Weil ihre Dokumente von Menschen geschrieben und geprüft werden. YAMLs Kommentare lassen ein Manifest sich selbst inline erklären, Einrückung hält tiefe Ressourcenspezifikationen lesbar, und Diffs zeigen die Absicht klar. Dasselbe, das YAML für den Austausch riskant macht – Ableitung, Einrückungsempfindlichkeit –, ist für von Hand gepflegte Konfiguration eine Stärke.

Was ist das Norwegen-Problem in YAML?

Mehrere YAML-Parser typisieren nackte Skalare per Ableitung, daher parst ein Ländercode wie NO (Norwegen) als boolean false, und off oder on werden ebenfalls zu Booleans. Die Lösung ist, jeden Wert zu quoten, der ein String bleiben soll. JSON ist von Konstruktion immun – ohne Anführungszeichen bedeutet Zahl oder Boolean, mit Anführungszeichen String, ohne einen Ableitungsschritt, der schiefgehen könnte.

Kann die Konvertierung von YAML zu JSON Daten verlieren?

Ja, in drei dokumentierten Fällen: mehrere Dokumente in einer Datei (nur das letzte überlebt einen Einzeldokument-Konverter), Anker und Aliase (sie müssen expandiert werden, was Inhalte dupliziert) und Nicht-String-Schlüssel. Die Konverter dieser Site weisen diese Fälle zurück oder melden sie klar, statt das Dokument still umzuformen.

Soll ich YAML mit 2 oder 4 Leerzeichen einrücken?

Beides ist gültig – YAML verbietet Tabs, nicht eine Leerzeichenanzahl –, aber 2 Leerzeichen sind die überwältigende Konvention in den Kubernetes-, CI- und Docker-Ökosystemen, und gemischte Breiten innerhalb einer Datei sind der Ursprung von Einrückungsfehlern. Nehmen Sie 2, erzwingen Sie es mit Ihrem Editor, und jeder Diff bleibt lesbar.

Wo kann ich die hier zitierten Standards nachlesen?

RFC 8259 — Das Datenaustauschformat JavaScript Object Notation (JSON)
YAML 1.2 — YAML-Spezifikation, Version 1.2 (Revision 1.2.2)

ToolsByUs-Team · Wie wir unsere Tools prüfen

JSON vs. YAML erklärt