JSON vs YAML — Unterschiede erklärt

Dir ist wahrscheinlich aufgefallen, dass manche Projekte .json-Dateien für Config verwenden, während andere .yaml oder .yml nutzen. Beide Formate repräsentieren strukturierte Daten. Beide sind menschenlesbar. Was ist also der echte Unterschied, und wann solltest du welches wählen?

Ich habe beide ausgiebig genutzt — JSON ist mein täglicher Treiber für APIs und Datenaustausch, YAML ist mein Go-to für Kubernetes-Manifeste, GitHub Actions und Docker Compose. Sie lösen ähnliche Probleme, haben aber sehr unterschiedliche Persönlichkeiten.

Nebeneinander: Dieselbe Config in beiden Formaten

Hier ist ein Datenbank-Config-Objekt in JSON:

{
  "database": {
    "host": "localhost",
    "port": 5432,
    "name": "myapp",
    "ssl": true,
    "pool": {
      "min": 2,
      "max": 10
    },
    "replicas": ["replica1.db", "replica2.db"]
  }
}

Und hier ist dieselbe Config in YAML:

database:
  host: localhost
  port: 5432
  name: myapp
  ssl: true
  pool:
    min: 2
    max: 10
  replicas:
    - replica1.db
    - replica2.db

YAML ist sichtbar weniger überladen. Keine Anführungszeichen bei den meisten Strings, keine geschweiften Klammern, keine Kommas. Bei einer Config-Datei, die Menschen regelmäßig bearbeiten, summiert sich diese Klarheit. Aber YAML erkauft das durch deutlich mehr Komplexität unter der Haube.

Wo YAML glänzt

• Manuell bearbeitbare Config-Dateien. CI/CD-Pipelines (GitHub Actions, GitLab CI), Kubernetes-Manifeste, Docker Compose, Ansible-Playbooks. Alles YAML. Kein Zufall — das sind Dateien, die Menschen von Hand schreiben.
• Kommentare. YAML unterstützt Kommentare mit #. Das ist riesig für Config-Dateien, wo du erklären willst, warum eine Einstellung so ist. JSON unterstützt keine Kommentare.
• Mehrzeilige Strings. YAML hat Block-Skalare für mehrzeilige Inhalte, die sich natürlich lesen. JSON erfordert \n-Escape-Sequenzen.
• Weniger visuelles Rauschen. Kein Bedarf, die meisten Strings zu quoten, keine schließenden Klammern, keine Trailing Commas, über die du dir Sorgen machen musst.
• Anker und Aliases. YAML lässt dich einen Wert einmal definieren und überall anders mit &anchor und *alias referenzieren — praktisch für DRY-Config-Dateien.

Wo JSON gewinnt

• Striktheit. JSON hat eine einzige gültige Darstellung für jede Datenstruktur. YAML hat ein Dutzend Wege, dasselbe zu schreiben, was zu Inkonsistenz im Team führt.
• Keine Einrückungsfallen. JSON verwendet Klammern. YAML verwendet Einrückung, d.h. ein einziger falsch platzierter Leerraum kann deine gesamte Config stillschweigend kaputtmachen.
• Parse-Performance. JSON-Parser sind schnell und einfach. YAML-Parser sind komplex — YAML 1.1 hat notorisch knifflige implizite Typ-Coercion-Regeln.
• Universeller Library-Support. Jede Sprache hat einen battle-getesteten JSON-Parser ohne Abhängigkeiten. YAML-Libraries variieren in Qualität und Spec-Konformität.
• Tooling. Linter, Formatter, Schema-Validatoren — JSON-Tooling ist ausgereifter und breiter verfügbar.
• API-Payloads. JSON ist die Universalsprache der Web-APIs. YAML über HTTP zu schicken wäre unkonventionell und würde Reibung erzeugen.

Die YAML-Fallen, die dich erwischen werden

YAML hat einige wirklich überraschende Verhaltensweisen, die echte Production-Vorfälle verursacht haben. Die meisten kommen von den impliziten Typregeln in YAML 1.1, die YAML 1.2 gestrafft hat. Kenn diese, bevor du YAML für etwas Kritisches einsetzt:

# YAML 1.1 implicit type coercion — all of these become booleans:
enabled: yes   # → true
disabled: no   # → false
country: NO    # → false (!)  ← the Norway Problem

# Safe practice: quote strings that look like booleans
country: "NO"
enabled: "yes"

• Oktale Integer. In YAML 1.1 wird 010 als 8 (oktal) geparst, nicht als 10. Relevant für Dinge wie Dateirechte.
• Tabs vs. Leerzeichen. YAML verbietet Tabs für Einrückung. Ein einziger Tab aus einem Code-Editor lässt deine Datei stillschweigend oder mit einem kryptischen Fehler kaputtgehen.
• Implizite Nulls. Ein leerer Wert in YAML wird zu null. Beim manuellen Bearbeiten leicht zu übersehen.
• String-vs.-Zahl-Ambiguität. port: 8080 ergibt einen Integer. version: 1.0 kann einen Float ergeben. Manchmal willst du den String "1.0". Verwende immer Anführungszeichen, wenn es drauf ankommt.

Praktischer Entscheidungsleitfaden

Greif zu YAML wenn:

• Du Config-Dateien schreibst, die Menschen direkt bearbeiten: CI/CD, Kubernetes, Docker Compose, Ansible
• Die Datei Kommentare haben soll, die die Einstellungen erklären
• Mehrzeilige String-Werte häufig sind
• Das Ökosystem, in dem du arbeitest, bereits YAML nutzt (kämpf nicht gegen die Konvention)

Greif zu JSON wenn:

• Du Daten über eine API sendest oder empfängst
• Die Daten programmatisch generiert und konsumiert werden (keine menschliche Bearbeitung)
• Du garantierte Parse-Konsistenz über verschiedene Tools und Sprachen hinweg brauchst
• Du in einem Ökosystem arbeitest, das auf JSON standardisiert: npm (package.json), VS Code (settings.json), Angular, TypeScript

Zwischen den Formaten konvertieren

Musst du YAML-Config in JSON umwandeln für ein Tool, das kein YAML spricht? Nutze den YAML-zu-JSON-Konverter. Andersherum? Der JSON-zu-YAML-Konverter erledigt das. Der YAML Formatter ist auch praktisch, wenn du YAML einfügst, das aus der Ausrichtung geraten ist. Und wenn dein YAML nicht parst, sagt dir der YAML Validator genau, wo das Problem liegt.

Fazit

JSON und YAML sind komplementär, nicht konkurrierend. Nutze JSON für Datenaustausch — APIs, programmatische Datenspeicherung, Serialisierung. Nutze YAML für Config-Dateien, die Menschen lesen und bearbeiten. Die meisten reifen Projekte nutzen beide: package.json für Abhängigkeiten, .github/workflows/*.yml für CI. Wenn du verstehst, wofür jedes Format optimiert ist, wird die Entscheidung offensichtlich.