JSON vs YAML: der direkte Vergleich zweier Datenformate

JSON und YAML beschreiben im Kern dasselbe: strukturierte Daten aus Objekten, Listen und einfachen Werten. Was sie unterscheidet, ist nicht das, was du ausdrücken kannst, sondern die Art, wie du es aufschreibst. Beide Formate lassen sich verlustarm ineinander umwandeln, und genau deshalb landen sie ständig nebeneinander in denselben Projekten.

JSON stammt aus JavaScript. Douglas Crockford hat das Format Anfang der 2000er Jahre aus der Objekt-Literal-Syntax der Sprache abgeleitet und populär gemacht. Später wurde es in RFC 8259 standardisiert und ist heute das Standardformat für Programmierschnittstellen (APIs) im Web. YAML gibt es seit 2001 und wurde von Anfang an mit dem Ziel entworfen, für Menschen gut lesbar zu sein. Der Name steht (augenzwinkernd) für “YAML Ain’t Markup Language” und deutet an, dass es nicht um Auszeichnung wie bei HTML geht, sondern um Datenserialisierung.

In diesem Ratgeber schauen wir uns beide Formate nebeneinander an: Syntax, Lesbarkeit, Datentypen, Kommentare, Werkzeug-Support und Fehleranfälligkeit. Am Ende stehen ein paar klare Faustregeln, wann du zu welchem Format greifen solltest.

Was ist JSON?

JSON (JavaScript Object Notation) ist ein textbasiertes Datenformat, das auf zwei Grundstrukturen aufbaut: Objekte (Schlüssel-Wert-Paare in geschweiften Klammern) und Arrays (geordnete Listen in eckigen Klammern). Ein typisches JSON-Dokument sieht so aus:

{
  "name": "Serverkonfiguration",
  "port": 8080,
  "aktiv": true,
  "hosts": ["web-01", "web-02"]
}

JSON ist bewusst minimal gehalten. Die Grammatik ist streng: Schlüssel und Zeichenketten stehen immer in doppelten Anführungszeichen, Elemente werden mit Kommas getrennt, und nach dem letzten Element darf kein Komma stehen (kein “trailing comma”). Diese Strenge ist ein Vorteil, denn sie macht das Format eindeutig und für Maschinen sehr schnell zu verarbeiten. Praktisch jede Programmiersprache bringt einen JSON-Parser mit, oft sogar in der Standardbibliothek.

Was ist YAML?

YAML (YAML Ain’t Markup Language) verfolgt dasselbe Ziel wie JSON, setzt aber auf Einrückung statt auf Klammern. Dieselben Daten wie oben sehen in YAML so aus:

name: Serverkonfiguration
port: 8080
aktiv: true
hosts:
  - web-01
  - web-02

Die Hierarchie ergibt sich hier aus der Einrückung mit Leerzeichen, so wie du es aus eingerückten Textstrukturen kennst. Es gibt weniger “Rauschen” durch Klammern und Anführungszeichen. Zeichenketten müssen in den meisten Fällen nicht gequotet werden. Ein interessanter Punkt am Rande: Weil YAML 1.2 eine Obermenge von JSON ist, ist jedes gültige JSON-Dokument auch gültiges YAML. Umgekehrt gilt das nicht.

Syntax im Vergleich (Klammern vs Einrückung)

Der auffälligste Unterschied ist die Struktur-Markierung. JSON macht Verschachtelung durch geschweifte und eckige Klammern explizit sichtbar. Die Einrückung ist dabei reine Kosmetik, du könntest ein ganzes JSON-Dokument auch in eine einzige Zeile schreiben, und es bliebe gültig.

YAML dreht das um: Die Einrückung ist bedeutungstragend. Sie legt fest, welches Element zu welcher Ebene gehört. Ein Leerzeichen zu viel oder zu wenig verändert die Struktur oder erzeugt einen Fehler. Dafür entfällt fast alles an sichtbaren Trennzeichen. Wenn du die Details der YAML-Notation vertiefen willst (etwa Blockstil gegen Flow-Stil oder das Quoten von Sonderzeichen), findest du sie im Ratgeber YAML-Syntax-Grundlagen. Für die Klammer-Logik von JSON lohnt sich der Blick in die JSON-Struktur-Grundlagen.

Lesbarkeit

Für das reine Lesen durch Menschen hat YAML meist die Nase vorn, besonders bei tief verschachtelten Konfigurationen. Weniger Klammern und Anführungszeichen bedeuten weniger visuelle Ablenkung, und die Einrückung spiegelt die Struktur direkt wider. Genau deshalb setzen viele Konfigurationswerkzeuge auf YAML.

JSON ist dafür kompakter und maschinennäher. Für einen Menschen kann tief verschachteltes JSON mit vielen Klammern anstrengend werden, für einen Parser ist es dagegen ideal. Ein ehrlicher Hinweis: Bei sehr großen oder tief verschachtelten Dokumenten kippt der Lesbarkeitsvorteil von YAML manchmal, weil man bei vielen Einrückungsebenen leicht den Überblick über die aktuelle Tiefe verliert.

Kommentare (YAML ja, JSON nein)

Ein handfester, praktischer Unterschied: YAML erlaubt Kommentare, JSON nicht. In YAML leitest du einen Kommentar mit einem Rautezeichen ein:

port: 8080  # Standard-Port für den Webserver
# Diese Zeile wird vom Parser ignoriert
timeout: 30

In reinem JSON gibt es dafür keine Entsprechung. Ein “Kommentar” wäre schlicht ungültige Syntax. Genau das ist einer der Hauptgründe, warum YAML bei Konfigurationsdateien so beliebt ist: Man kann Optionen direkt im Dokument erklären, ohne eine separate Dokumentation zu pflegen. Wer in JSON Kommentare braucht, weicht in der Praxis oft auf Varianten wie JSON5 oder JSONC aus, die aber nicht dem RFC-8259-Standard entsprechen und nicht überall unterstützt werden.

Datentypen

JSON kennt eine überschaubare, klar definierte Menge an Typen: Zeichenkette (string), Zahl (number), Wahrheitswert (boolean), den Nullwert (null), Objekt und Array. Das ist alles. Daten wie ein Datum werden in JSON typischerweise als Zeichenkette dargestellt, und die Interpretation überlässt man der Anwendung.

YAML deckt dieselben Grundtypen ab, bietet aber mehr. Es kennt zusätzliche skalare Typen, darunter eine native Datums- und Zeitschreibweise, und es unterstützt Anker (Anchors) und Aliase, mit denen du einen Datenblock einmal definierst und an anderer Stelle wiederverwendest:

standard: &default
  timeout: 30
  retries: 3

server_a:
  <<: *default
  host: web-01

server_b:
  <<: *default
  host: web-02

Hier definiert &default einen Anker, und *default verweist darauf. Das spart Wiederholung, macht das Format aber auch mächtiger und damit potenziell komplexer. Diese Zusatzfähigkeiten haben eine Kehrseite: Bei der Umwandlung von YAML nach JSON gehen Kommentare, Anker-Struktur und native Datumstypen verloren, weil JSON dafür kein Gegenstück hat. Welche Details bei einer Konvertierung sonst noch verloren gehen können, behandelt der Ratgeber Fallstricke der JSON-YAML-Konvertierung.

Werkzeug- und Sprach-Support

Beim reinen Support hat JSON einen Vorsprung. Es ist so verbreitet, dass fast jede Sprache es ohne zusätzliche Bibliothek lesen und schreiben kann. Im Browser gehört es über die eingebauten Funktionen JSON.parse und JSON.stringify zum Standard, und APIs im Web tauschen ihre Daten fast durchgängig in JSON aus.

YAML ist ebenfalls breit unterstützt, benötigt in vielen Sprachen aber eine externe Bibliothek. Im Ökosystem der Konfiguration ist es dafür allgegenwärtig, etwa bei Werkzeugen für Container-Orchestrierung, Build-Pipelines und Infrastruktur-Automatisierung. Beide Formate kannst du direkt auf jsonyaml.de ausprobieren: Der Konverter wandelt JSON und YAML live und in beide Richtungen um, und zwar vollständig lokal in deinem Browser, ohne dass deine Daten irgendwohin hochgeladen werden.

Fehleranfälligkeit (YAML-Einrückung)

Die Stärke von YAML ist zugleich seine größte Fehlerquelle: die bedeutungstragende Einrückung. Ein versehentliches Tabulatorzeichen statt Leerzeichen, eine um zwei Stellen verrutschte Zeile oder ein fehlender Doppelpunkt kann die Struktur still verändern oder einen schwer zu findenden Fehler auslösen. Berüchtigt ist auch das sogenannte “Norway-Problem”: In älteren YAML-Versionen wurde no (etwa als Länderkürzel für Norwegen) fälschlich als Wahrheitswert false interpretiert, wenn man es nicht in Anführungszeichen setzte.

JSON ist hier robuster, weil die Struktur durch Klammern eindeutig festgelegt ist und die Einrückung keine Rolle spielt. Dafür bestraft JSON die typischen Anfängerfehler streng: ein Komma zu viel am Listenende, einfache statt doppelter Anführungszeichen oder ein vergessenes Komma zwischen zwei Feldern führen sofort zu einem Parse-Fehler. Beide Formate haben also ihre eigenen typischen Stolpersteine, nur an unterschiedlichen Stellen.

Vergleichstabelle

Merkmal	JSON	YAML
Struktur-Markierung	Klammern	Einrückung
Kommentare	nein	ja (mit #)
Lesbarkeit für Menschen	gut, aber klammerlastig	sehr gut, besonders bei Konfiguration
Datentypen	string, number, boolean, null, object, array	wie JSON, plus Datum, Anker/Alias
Sprach-Support	überall, oft in der Standardbibliothek	breit, oft externe Bibliothek nötig
Kompaktheit	sehr kompakt	etwas ausführlicher
Fehlerquelle	Kommas, Anführungszeichen	Einrückung, Tabulatoren
Typischer Einsatz	APIs, Datenaustausch	Konfigurationsdateien

Faustregeln: wann welches Format?

Die Entscheidung fällt in der Praxis meist entlang einer einfachen Linie: Wer liest oder verarbeitet die Daten überwiegend?

Nimm JSON, wenn Maschinen die Hauptleser sind. Für APIs, den Datenaustausch zwischen Diensten, das Speichern strukturierter Daten und alles, was schnell und eindeutig geparst werden muss, ist JSON die sichere Wahl. Der universelle Support und die strenge, unmissverständliche Grammatik zahlen sich hier direkt aus.

Nimm YAML, wenn Menschen die Datei regelmäßig lesen und bearbeiten. Für Konfigurationsdateien, in denen Kommentare erklären, was eine Option bewirkt, und in denen eine ruhige, klammerarme Struktur die Wartung erleichtert, spielt YAML seine Stärken aus. Die Frage, in welchen konkreten Situationen sich der Wechsel lohnt, vertieft der Ratgeber Wann YAML statt JSON?.

In vielen Projekten leben beide Formate nebeneinander: YAML für die von Menschen gepflegte Konfiguration, JSON für die maschinelle Kommunikation dahinter. Weil sich die Formate ineinander umwandeln lassen, ist das kein Widerspruch, sondern eine sinnvolle Arbeitsteilung. Am schnellsten bekommst du ein Gefühl für die Unterschiede, indem du dasselbe Dokument einmal in JSON und einmal in YAML nebeneinander betrachtest, was auf jsonyaml.de mit einem Klick geht.

Hast du einen Fehler entdeckt oder einen Quellen-Hinweis für uns? Schreib gern an info@akara-solutions.de.