JSON vs YAML — Wann was verwenden

JSON und YAML sind beides Möglichkeiten, strukturierte Daten als Text darzustellen. Beide unterstützen Strings, Zahlen, Booleans, Arrays und verschachtelte Objekte. Beide werden von jeder Programmiersprache und Plattform breit unterstützt. Dennoch machen sie sehr unterschiedliche Trade-offs: JSON optimiert für maschinelle Lesbarkeit und Parse-Geschwindigkeit; YAML optimiert für menschliche Lesbarkeit und ausdrucksstarke Konfiguration. Zu wissen, wann welches Format verwendet werden sollte, verhindert die Reibung, die entsteht, wenn man ein für APIs konzipiertes Konfigurationsformat für handgeschriebene Config-Dateien verwendet — oder umgekehrt.

Dieser Leitfaden behandelt die Syntaxunterschiede, die praktischen Stärken und Schwächen jedes Formats, reale Tool-Entscheidungen, die vom Format abhängen, Leistungsüberlegungen und ein klares Entscheidungsframework für 2026.

JSON: Überblick

JSON (JavaScript Object Notation) wurde von Douglas Crockford in den frühen 2000ern formalisiert und in RFC 8259 und ECMA-404 standardisiert. Sein Designziel war ein minimales, eindeutiges Format, das von jeder Programmiersprache ohne komplexen Parser geparst und serialisiert werden kann.

JSON unterstützt genau sechs Datentypen: Strings (immer in doppelten Anführungszeichen), Zahlen, Booleans (true/false), null, Objekte (Schlüssel-Wert-Maps mit String-Schlüsseln) und Arrays (geordnete Listen). Es gibt keine Kommentare, keine Datumstypen, keine Binärtypen, keine Referenzen. Dieser Minimalismus ist beabsichtigt: Die strengen Regeln eliminieren Mehrdeutigkeit und machen Parser einfach und schnell.

{
  "name": "deploy-service",
  "version": "2.1.0",
  "environment": "production",
  "replicas": 3,
  "enabled": true,
  "tags": ["backend", "critical"],
  "resources": {
    "cpu": "500m",
    "memory": "512Mi"
  }
}

Jeder Schlüssel muss in doppelten Anführungszeichen stehen. Nachfolgende Kommas sind nicht erlaubt. Es gibt keine Möglichkeit, einen Kommentar zu schreiben. Strings können nicht ohne Escaping des Zeilenumbruchzeichens mehrere Zeilen umfassen. Diese Einschränkungen machen JSON schwieriger von Hand zu schreiben, aber trivial einfach aus Code zu generieren und beim Empfänger zu parsen.

YAML: Überblick

YAML (YAML Ain't Markup Language) wurde ab 2001 von Clark Evans, Ingy dot Net und Oren Ben-Kiki entwickelt. Version 1.2, die JSON-Kompatibilität erreicht, wurde 2009 fertiggestellt. YAMLs Designziel ist ein menschenlesbares Datenformat, das Entwickler direkt in Texteditoren schreiben können, ohne eine neue Syntax zu erlernen. Die vollständige Spezifikation ist unter yaml.org zu finden.

YAML verwendet Einrückung, um Struktur auszudrücken, anstatt Klammern. Listen verwenden Bindestriche. Schlüssel sind standardmäßig ohne Anführungszeichen. Kommentare beginnen mit #. Strings erfordern keine Anführungszeichen, es sei denn, sie enthalten Sonderzeichen. Mehrzeilige Strings haben eine dedizierte Block-Skalar-Syntax.

# Deployment configuration for production
name: deploy-service
version: 2.1.0
environment: production
replicas: 3
enabled: true

tags:
  - backend
  - critical

resources:
  cpu: 500m
  memory: 512Mi

Die gleiche Datenstruktur in YAML ausgedrückt ist deutlich kürzer und lesbarer — besonders wenn Kommentare oder verschachtelte Listen enthalten sind. Der Trade-off ist, dass YAMLs Parser erheblich mehr Komplexität verarbeiten muss: Einrückungsempfindlichkeit, mehrere Möglichkeiten, denselben Typ auszudrücken, Anker, Aliase, Merge-Schlüssel und ein historisches Erbe mehrdeutiger Boolean-Interpretation.

Syntaxvergleich nebeneinander

Mehrzeilige Strings

Mehrzeilige Strings sind einer von YAMLs deutlichsten Vorteilen für Konfigurationsdateien. YAML bietet zwei Block-Skalar-Stile: Literal (|) bewahrt Zeilenumbrüche exakt, und Folded (>) verbindet Zeilen mit Leerzeichen für langen Fließtext.

# YAML: multiple ways to write multi-line strings
# Literal block (preserves newlines)
description: |
  This is line one.
  This is line two.
  Final line with trailing newline.

# Folded block (newlines become spaces, good for long prose)
summary: >
  This long paragraph is written across
  multiple lines but will be joined into
  a single space-separated string.

# In JSON, you must escape newlines
# "description": "This is line one.\nThis is line two.\nFinal line."

Anker und Aliase

YAML-Anker (&) und Aliase (*) ermöglichen es Ihnen, einen Wert einmal zu definieren und an mehreren Stellen zu referenzieren, ähnlich wie eine Variable. Der Merge-Schlüssel (<<) fügt die Inhalte eines Mappings in ein anderes ein und bietet so eine Form von Vererbung.

# YAML anchors and aliases reduce duplication
defaults: &defaults
  timeout: 30
  retries: 3
  log_level: info

development:
  <<: *defaults   # merge defaults
  log_level: debug

staging:
  <<: *defaults
  timeout: 60

production:
  <<: *defaults

JSON hat kein Äquivalent. In JSON muss wiederkehrende Konfiguration dupliziert, durch eine Templating-Schicht verwaltet oder von der Logik der konsumierenden Anwendung behandelt werden. YAML-Anker sind leistungsstark für manuell gepflegte Configs, können aber Dateien für Leser, die mit der Konvention nicht vertraut sind, schwerer verständlich machen.

Stärken und Schwächen

JSON-Stärken

• Eindeutiges Parsen — die Grammatik ist einfach genug, um auf einer einzelnen Seite zu beschreiben. Jeder Parser erzeugt das gleiche Ergebnis für eine gegebene Eingabe.
• Geschwindigkeit — JSON-Parser gehören zu den schnellsten Text-Parsern überhaupt. V8 parst JSON erheblich schneller als JavaScript ausgeführt wird.
• Native JavaScript-Unterstützung — JSON.parse() und JSON.stringify() sind in jeder JavaScript-Laufzeitumgebung eingebaut. Keine Abhängigkeiten nötig.
• Universelles Tooling — jeder API-Client, jede Datenbank und jede Datenpipeline spricht nativ JSON. Es ist das De-facto-API-Format.
• Keine Einrückungsempfindlichkeit — Leerzeichen sind für die Bedeutung irrelevant, was JSON gegenüber Formatierungsunterschieden zwischen Editoren, Betriebssystemen und Tools robust macht.

JSON-Schwächen

• Keine Kommentare — Sie können einen Konfigurationswert nicht inline erklären. Das ist ein erheblicher Schmerzpunkt für von Hand geschriebene Dateien.
• Ausführlich für Menschen — alle Schlüssel müssen in Anführungszeichen stehen, Kommas trennen jedes Element, und Klammern umgeben jedes Objekt und Array.
• Nachfolgende Kommafehler — nachfolgende Kommas nach dem letzten Array- oder Objekt-Element sind ungültig und verursachen Parse-Fehler, die beim manuellen Editieren leicht eingeführt werden.
• Keine mehrzeiligen Strings — einen String mit eingebetteten Zeilenumbrüchen darzustellen erfordert \n-Escaping, was SQL-Queries oder Shell-Skripte schmerzhaft zum Einbetten macht.
• Kein Datumstyp — Daten sind Strings. Konventionen variieren (ISO 8601, Unix-Timestamps, eigene Formate) und müssen von der Anwendung verarbeitet werden.

YAML-Stärken

• Kommentare — die #-Kommentarsyntax macht YAML zur offensichtlichen Wahl für Konfigurationsdateien, die inline-Dokumentation benötigen.
• Lesbarkeit — weniger syntaktisches Rauschen. Schlüssel ohne Anführungszeichen, keine Kommas, einrückungsbasierte Struktur, die widerspiegelt, wie Menschen Gliederungen schreiben.
• Mehrzeilige Strings — Literal- und Folded-Block-Skalare behandeln lange Strings problemlos ohne Escaping.
• Anker und Merge-Schlüssel — reduzieren Duplikation in großen Konfigurationsdateien.
• Reiches Typsystem — YAML-Parser schließen Typen aus dem Wertformat (Strings, Ganzzahlen, Floats, Booleans, null, Timestamps) ohne explizite Typ-Annotationen.

YAML-Schwächen

• Komplexität — die vollständige YAML-Spezifikation ist riesig. Sonderfälle sind zahlreich: das Norwegen-Problem, implizite Typkonvertierungsüberraschungen, Tab-vs-Leerzeichen-Empfindlichkeit.
• Langsames Parsen — YAML-Parser sind aufgrund der Grammatikkomplexität erheblich langsamer als JSON-Parser.
• Einrückungsfehler — eine einzige falsch ausgerichtete Zeile ändert die Bedeutung des Dokuments, ohne einen Parse-Fehler zu erzeugen, was subtile Bugs erzeugt, die schwer zu erkennen sind.
• Das Norwegen-Problem — in YAML 1.1 wird das bloße NO als boolesches false geparst. Ländercodes, Abkürzungen und viele englische Wörter haben unerwartete Boolean-Interpretationen in YAML 1.1-Parsern (noch immer verbreitet).
• Inkonsistentes Parser-Verhalten — verschiedene Sprachen-YAML-Parser implementieren unterschiedliche Teilmengen der Spezifikation oder verschiedene Versionen, was zu Portabilitätsproblemen führt.

Wann JSON verwenden

API-Antworten und -Anfragen

JSON ist das universelle Format für REST-APIs. Jede HTTP-Client-Bibliothek kann es nativ serialisieren und deserialisieren. Parse-Geschwindigkeit ist auf API-Ebene wichtig, und JSONs eindeutige Grammatik bedeutet, dass jeder Client und Server dieselben Daten identisch parst. GraphQL-Antworten sind JSON. OpenAPI/Swagger-Definitionen sind JSON (obwohl YAML auch akzeptiert wird). Wenn Sie eine API entwerfen, standardmäßig JSON verwenden.

{
  "user": {
    "id": 42,
    "email": "alice@example.com",
    "roles": ["admin", "editor"],
    "createdAt": "2026-01-15T10:30:00Z"
  }
}

Von Code generierte Konfiguration

Wenn ein Programm Konfiguration generiert — ein Build-Tool gibt Abhängigkeitslockdateien aus, ein Framework generiert ein Projektmanifest, ein Deployment-Tool zeichnet Prüfsummen auf — ist JSON das richtige Format. Die Ausgabe muss nie von Hand geschrieben werden, es gibt keinen Bedarf für Kommentare, und JSONs eindeutige Grammatik stellt sicher, dass der konsumierende Code genau das parst, was generiert wurde. package.json, tsconfig.json, package-lock.json und composer.json sind alle Beispiele für dieses Muster.

Datenaustausch zwischen Services

Wenn zwei Services Daten austauschen müssen — Message Queues, Webhooks, Event Streams — machen JSONs Geschwindigkeit, Universalität und Eindeutigkeit es zur richtigen Wahl. YAMLs Vorteile (Kommentare, mehrzeilige Strings) sind in automatisierten Datenpipelines irrelevant. Verwenden Sie den JSON Formatter, um Payloads beim Debuggen zu inspizieren, und den JSON-zu-YAML-Konverter, wenn Sie einen Payload für Dokumentationszwecke menschenlesbar machen müssen.

Speicherung in Datenbanken

PostgreSQL, MongoDB, MySQL und die meisten Datenbanken, die strukturierte Daten speichern, tun dies in JSON oder JSON-kompatiblen Formaten. YAML ist kein unterstütztes Speicherformat in einer der großen Datenbanken. Wenn Sie Konfiguration oder strukturierte Daten in einer Datenbank speichern, verwenden Sie JSON.

Wann YAML verwenden

Infrastruktur- und Deployment-Konfiguration

Kubernetes-Manifeste, Helm-Charts, Docker-Compose-Dateien und Ansible-Playbooks verwenden alle YAML. Diese Dateien werden von Menschen geschrieben und überprüft, enthalten oft erklärende Kommentare und profitieren von YAMLs lesbarer Listensyntax für die Beschreibung von Ressourcenmengen. Ein Kubernetes Deployment mit mehreren Containern, Volume-Mounts und Umgebungsvariablen ist in YAML erheblich leichter lesbar als in JSON.

CI/CD-Pipeline-Definitionen

GitHub Actions, GitLab CI, CircleCI und Bitbucket Pipelines verwenden alle YAML für Pipeline-Definitionen. Pipeline-Configs werden von Menschen geschrieben, häufig kommentiert und enthalten mehrstufige Logik, die von YAMLs lesbarer Syntax profitiert.

# GitHub Actions workflow — YAML natural fit
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test

Anwendungskonfigurationsdateien

Django-Settings (via django-configurations), Ruby on Rails database.yml, Gatsby-Config und viele andere Frameworks verwenden YAML für ihre Konfiguration. Wenn Entwickler eine Konfigurationsdatei neben dem Code lesen und verstehen müssen, reduziert YAMLs Fähigkeit, Kommentare und mehrzeilige Erklärungen einzubeziehen, den kognitiven Aufwand.

Dokumentationsdaten

Statische Site-Generatoren wie Jekyll, Hugo und Eleventy verwenden YAML-Frontmatter in Content-Dateien. Die Kombination aus YAML-Metadaten und Markdown-Body-Inhalten ist weit verbreitet, weil YAMLs lesbare Schlüssel-Wert-Syntax natürlich an den Anfang eines Textdokuments passt. JSON-Frontmatter existiert, wird aber selten bevorzugt.

Leistung

Für Datenverarbeitungspipelines zeigen Serialisierungs-Benchmarks konstant, dass JSON 5-10x schneller zu parsen ist als YAML für äquivalente Daten. Ein V8-JSON.parse()-Aufruf auf einer 1-MB-Datei wird in wenigen Millisekunden abgeschlossen. Das äquivalente YAML-Parsing dauert Dutzende von Millisekunden. Für einen Webserver, der tausende Anfragen pro Sekunde verarbeitet, ist dieser Unterschied wichtig. Für ein CLI-Tool, das beim Start einmalig eine Config-Datei liest, ist er es nicht.

Wenn Leistung Ihr primäres Anliegen ist und Sie zwischen JSON und YAML für ein hochdurchsatzstarkes Datenformat wählen, gewinnt JSON ohne Frage. Wenn Sie noch schnelleres Parsen benötigen, erwägen Sie Binärformate wie MessagePack oder Protocol Buffers für die Kommunikation zwischen Services.

Sicherheitsüberlegungen

YAML-Parser sind komplexer und haben eine größere Angriffsfläche als JSON-Parser. Das gravierendste Risiko ist die willkürliche Codeausführung via YAML-Deserialisierung. In Pythons PyYAML (bevor safe_load standardmäßig erzwungen wurde) konnte das Laden von nicht vertrauenswürdigem YAML mit der Standard-Funktion yaml.load() willkürlichen Python-Code ausführen, der im YAML eingebettet war. Die PHP- und Ruby-YAML-Parser hatten ähnliche Schwachstellen.

Die Regel: Verwenden Sie immer sicheres Laden beim Parsen von nicht vertrauenswürdigem YAML. In Python verwenden Sie yaml.safe_load(), niemals yaml.load() ohne das Loader-Argument. In Java konfigurieren Sie den Konstruktor, um erlaubte Typen einzuschränken. In Ruby verwenden Sie YAML.safe_load() statt YAML.load().

JSON-Parser haben diese Schwachstelle nicht, weil JSONs Typsystem kein Konzept ausführbarer Werte hat. Ein JSON-Parser kann nur Strings, Zahlen, Booleans, null, Arrays und Objekte erzeugen — niemals Code. Für die Verarbeitung nicht vertrauenswürdiger Benutzerdaten ist JSON inhärent sicherer zu parsen.

Zwischen JSON und YAML konvertieren

Die Formate sind semantisch kompatibel für die häufigsten Datentypen. Das Konvertieren zwischen ihnen ist unkompliziert, wenn die Daten keine YAML-spezifischen Features verwenden (Anker, benutzerdefinierte Typen, Block-Skalare). Verwenden Sie den JSON-zu-YAML-Konverter, um API-Antworten oder Lockdateien in lesbares YAML für Dokumentation oder Debugging zu transformieren. Verwenden Sie den YAML-zu-JSON-Konverter, um YAML-Konfiguration in JSON-native Tools oder APIs einzuspeisen. Beide Tools laufen im Browser — Ihre Daten verlassen nie Ihr Gerät.

Der JSON Formatter ist nützlich, um JSON-Struktur zu inspizieren und zu validieren, bevor Sie konvertieren. Wenn Sie mit Konfigurationen arbeiten, die häufig zwischen Formaten wechseln — zum Beispiel Kubernetes-Manifeste, die für einen API-Aufruf serialisiert werden müssen — spart das Vorhalten beider Konverter als Lesezeichen Zeit.

Entscheidungsframework

• Schreiben Sie eine REST-API-Antwort oder -Anfrage? JSON.
• Konfigurieren Sie Kubernetes, Docker Compose oder Ansible? YAML.
• Schreiben Sie eine CI/CD-Pipeline? YAML.
• Speichern Sie Daten in einer Datenbank? JSON.
• Schreiben Sie eine von Menschen editierbare Config-Datei mit Kommentaren? YAML.
• Generieren Sie Config programmgesteuert aus Code? JSON.
• Verarbeiten Sie nicht vertrauenswürdige Benutzereingaben? JSON (sichererer Parser).
• Hochdurchsatzstarke Datenpipeline? JSON (oder Binärformat).
• Projekt, das bereits ein Format konsistent verwendet? Bestehende Konvention beibehalten.

Im Zweifel ist der wichtigste Faktor die Menschen, die die Datei lesen und schreiben werden. Wenn die Datei primär maschinengeniert und maschinell konsumiert wird, gewinnt JSONs Einfachheit. Wenn Menschen sie lesen, editieren und sich um ihre Klarheit kümmern, ist YAMLs Ausdrucksstärke die zusätzliche Parser-Komplexität wert.