YAML und JSON sind beide beliebte Dateiformate für Konfigurationsdateien zum Speichern strukturierter Daten, aber sie erfordern sehr unterschiedliche Kompromisse. YAML ist für menschliche Lesbarkeit konzipiert und nutzt Einrückungen sowie minimale Interpunktion, während JSON ein striktes, maschinenfreundliches Format ist, das auf geschweifte Klammern und Anführungszeichen aufbaut. Die Wahl zwischen ihnen hängt normalerweise davon ab, wer oder was die Datei am häufigsten liest.
Inhaltsverzeichnis
Was Sind YAML und JSON?
Beide Formate werden für Datenserialisierung verwendet, was einfach bedeutet, strukturierte Daten (Objekte, Listen, Schlüssel-Wert-Paare) in ein Textformat umzuwandeln, das in einer Datei gespeichert oder über ein Netzwerk gesendet werden kann. Sie überlappen sich stark in ihren Möglichkeiten, folgen aber unterschiedlichen Designphilosophien.
- JSON (JavaScript Object Notation) wurde in den frühen 2000er Jahren definiert und ist jetzt in RFC 8259 spezifiziert. Es entstand aus der JavaScript-Syntax und wurde zum Standard-Datenformat für REST-APIs.
- YAML (YAML Ain't Markup Language) wurde speziell dafür entwickelt, von Menschen lesbar zu sein. Es ist eine Obermenge von JSON, was bedeutet, dass jedes gültige JSON auch gültiges YAML ist, aber YAML bietet darüber hinaus viel mehr Flexibilität.
Syntax im Vergleich
Der schnellste Weg, den Unterschied zu verstehen, ist, die gleichen Daten in beiden Formaten zu betrachten. Hier ist eine einfache Anwendungskonfiguration als YAML- versus JSON-Beispiel:
YAML-Version:
server:
host: localhost
port: 8080
debug: true
database:
name: myapp_db
max_connections: 10
allowed_origins:
- https://example.com
- https://app.example.com
JSON-Version:
{
"server": {
"host": "localhost",
"port": 8080,
"debug": true
},
"database": {
"name": "myapp_db",
"max_connections": 10
},
"allowed_origins": [
"https://example.com",
"https://app.example.com"
]
}
Beide Dateien enthalten exakt die gleichen Daten. YAML nutzt Einrückungen, um Verschachtelung anzuzeigen. JSON nutzt geschweifte Klammern, eckige Klammern und Kommas. Die YAML-Version ist deutlich kürzer und leichter auf einen Blick zu erfassen.
Wichtigste Unterschiede
| Funktion | YAML | JSON |
|---|---|---|
| Kommentare |
Unterstützt mit
#
|
Nicht unterstützt |
| Anführungszeichen um Strings | In den meisten Fällen optional | Immer erforderlich |
| Nachfolgende Kommas | Nicht zutreffend | Nicht erlaubt (verursacht Parse-Fehler) |
| Mehrzeilige Strings |
Native Unterstützung (
|
und
>
Operatoren)
|
Erfordert
\n
Escape-Sequenzen
|
| Datentypen | Inferiert Typen automatisch | Explizit (Nummern, Strings, Booleans) |
| Anker und Aliase | Unterstützt (Blöcke wiederverwenden) | Nicht unterstützt |
| Parser-Verfügbarkeit | Gut, aber variiert je nach Bibliothek | In jeder modernen Sprache/Runtime integriert |
| Dateigröße | Typischerweise kleiner | Etwas größer aufgrund von Interpunktion |
yes
in YAML wird in vielen Parsern als Boolean
true
geparst, nicht als String "yes". Ländercode wie
NO
(Norwegen) oder Versionsnummern wie
1.0
können ebenfalls falsch interpretiert werden. Verwende immer Anführungszeichen um Strings, die mehrdeutig sein könnten.
Wann YAML Verwenden
YAML glänzt in Situationen, in denen Menschen die Konfigurationsdatei direkt schreiben und verwalten. Häufige Anwendungsfälle in der Praxis sind:
-
CI/CD-Pipelines
wie GitHub Actions (
.github/workflows/*.yml), GitLab CI (.gitlab-ci.yml) und CircleCI-Konfigurationen - Kubernetes-Manifeste , bei denen jede Ressourcendefinition eine YAML-Datei ist
-
Docker Compose
-Dateien (
docker-compose.yml) - Ansible-Playbooks und Inventory-Dateien
-
Anwendungskonfigurationsdateien
für Frameworks wie Ruby on Rails (
database.yml) und Spring Boot (application.yml)
Allein die Kommentarunterstützung ist ein großer Grund, warum Entwickler YAML für Konfigurationsdateien bevorzugen. Die Möglichkeit,
# This port must match the nginx upstream
direkt in der Datei zu schreiben, ist unbezahlbar in Team-Umgebungen, wo Kontext zählt.
YAML-Anker sind ein weiteres unterschätztes Feature. Du kannst einen Block einmal definieren und ihn wiederverwenden:
defaults: &defaults
timeout: 30
retries: 3
production:
<<: *defaults
host: prod.example.com
staging:
<<: *defaults
host: staging.example.com
Wann JSON Verwenden
JSON ist die bessere Wahl, wenn Maschinen die primären Konsumenten der Daten sind. Verwende JSON wenn:
- Du eine API aufbaust oder nutzt. REST-APIs verwenden fast universell JSON. Es bildet sich direkt auf JavaScript-Objekte ab und wird von Browsern nativ geparst, ohne dass zusätzliche Bibliotheken erforderlich sind.
- Du maximale Parser-Kompatibilität brauchst. JSON-Parser sind in Python, Node.js, Go, Java, Rust, Ruby und jedem großen Browser integriert. YAML-Parser sind externe Abhängigkeiten.
- Die Datei wird maschinell generiert. Tools, die Konfiguration oder Datendateien programmgesteuert schreiben (wie Paketmanager), geben normalerweise JSON aus, weil es einfacher ist, es korrekt zu serialisieren.
-
Du verwendest
package.json,tsconfig.jsonoder ähnliche Ecosystem-Dateien. Das Node.js- und TypeScript-Ökosystem folgt von Natur aus JSON-first. - Du brauchst strenge Validierung. JSON Schema ist ein ausgereifter, weit verbreiteter Standard zur Validierung der Struktur von JSON-Dokumenten. Für einen umfassenden Leitfaden zur Implementierung von Validierung in deinen Projekten, siehe unseren Artikel über JSON-Schema-Validierung.
Konvertierung Zwischen YAML und JSON
Die beiden Formate sind strukturell in den meisten Fällen äquivalent, daher ist die Konvertierung zwischen ihnen unkompliziert. Du wirst häufig YAML zu JSON konvertieren müssen, wenn ein Tool oder eine API JSON erwartet, aber deine Konfiguration in YAML geschrieben ist, oder wenn du deine YAML-Struktur leichter validieren möchtest.
Da YAML eine Obermenge von JSON ist, ist die Konvertierung für alle Standard-Datentypen verlustfrei. Die Hauptdinge, die eine YAML-zu-JSON-Konvertierung nicht überstehen, sind YAML-spezifische Features wie Kommentare, Anker und Aliase, da JSON keine Entsprechungen dafür hat.
Für eine schnelle browserbasierte Konvertierung, bei der keine Daten deine Maschine verlassen, kannst du ein dediziertes YAML-zu-JSON-Tool verwenden, das das Parsing und Formatierung automatisch handhabt. Das ist besonders praktisch, wenn du zwischen Infrastructure-as-Code-YAML-Dateien und API-Payloads wechselst, die in JSON sein müssen.
Konvertiere YAML zu JSON sofort, direkt in deinem Browser
Du arbeitest mit YAML- versus JSON-Konfigurationsdateien und musst schnell zwischen Formaten wechseln? Unser kostenloser YAML-zu-JSON-Konverter führt die Umwandlung auf der Client-Seite durch, sodass deine Konfigurationsdaten deine Maschine nie verlassen.
Probiere den YAML-zu-JSON-Konverter →
Nicht ganz. YAML ist eine Obermenge von JSON, daher kann es alles tun, was JSON tut, und noch mehr. Aber JSON wird nicht verschwinden, weil es der Standard für APIs und Maschinen-zu-Maschinen-Kommunikation ist. Denk an sie als komplementäre Tools: YAML für von Menschen bearbeitete Konfigurationsdateien, JSON für Datenaustausch zwischen Systemen.
Nein, Standard-JSON unterstützt keine Kommentare. Das ist eine der häufigsten Frustrationen von Entwicklern mit JSON-Konfigurationsdateien. Einige Tools wie VS Code unterstützen JSONC (JSON mit Kommentaren) für ihre eigenen Konfigurationsdateien, aber das ist kein Standard und wird in regulären JSON-Parsern nicht funktionieren. Wenn du Kommentare in deiner Konfiguration brauchst, ist YAML die bessere Wahl.
JSON ist generell schneller zu parsen, weil seine Grammatik einfacher ist und Parser hochoptimiert sind, oft direkt in Language-Runtimes integriert. YAML-Parser müssen mehr Syntax-Regeln, Typ-Inferenz und Features wie Anker handhaben. Für Konfigurationsdateien, die beim Start einmal gelesen werden, ist der Unterschied vernachlässigbar. Für High-Throughput-Daten-Streaming gewinnt JSON klar.
Die häufigsten Probleme sind inkonsistente Einrückungen (das Mischen von Tabs und Leerzeichen wird YAML zerstören), unquotierte Spezialwerte wie
yes
,
no
,
null
oder
on
werden als Booleans interpretiert, und Doppelpunkte in unquotierten Strings. Verwende immer Leerzeichen (keine Tabs) für Einrückungen, und quotiere jeden String-Wert, der mehrdeutig sein könnte.
Für Standard-Datentypen geht keine Daten verloren. Allerdings haben YAML-spezifische Features wie Kommentare, Anker und Aliase keine JSON-Entsprechungen und werden während der Konvertierung gelöscht. Anker werden zuerst aufgelöst (die referenzierten Werte werden eingefügt), und Kommentare werden einfach entfernt. Die eigentlichen Schlüssel-Wert-Daten und ihre Struktur bleiben vollständig erhalten.
YAML ist der Standard für Kubernetes und Docker Compose. Kubernetes-Manifeste werden fast immer in YAML geschrieben, und die offizielle Dokumentation nutzt YAML in allen Beispielen. Docker Compose-Dateien verwenden standardmäßig die
.yml
Erweiterung. Während Kubernetes technisch auch JSON akzeptiert, ist die Community-Konvention fest auf YAML für Lesbarkeit und Kommentarunterstützung.