YAML zu JSON — Wann konvertieren, wie es funktioniert und was verloren geht

Vor einigen Jahren half ich einem Team, seine CI/CD-Pipeline von einer Plattform auf eine andere zu migrieren. Das alte System verwendete JSON für Pipelinedefinitionen, das neue YAML. Theoretisch kein großes Problem — beide Formate beschreiben dieselben hierarchischen Daten, oder?

In der Praxis verbrachte ich eine beschämende Menge Zeit damit, Klammern in Einrückungen umzuformen, Anführungszeichen von Keys zu entfernen und mir zu merken, dass JSONs null in YAML ~ oder null wird, je nach Parser-Laune. Tedious, fehleranfällige Arbeit. Schließlich wies mich jemand auf ein Konverter-Tool hin und ich fühlte mich aufrichtig dumm dafür, keins von Anfang an genutzt zu haben.

Diese Erfahrung ist verbreitet. YAML und JSON sind in der modernen Entwicklung allgegenwärtig — CI-Configs, Docker Compose, Kubernetes-Manifeste, API-Antworten, Package-Metadaten — und sie überschneiden sich genug, dass man irgendwann Daten zwischen ihnen bewegen muss.

Was YAML und JSON wirklich sind

Keine der beiden ist eine Programmiersprache. Es sind Datenserialisierungsformate — Wege, strukturierte Daten als Text darzustellen, damit verschiedene Systeme sie lesen und schreiben können.

JSON (JavaScript Object Notation) wurde in den frühen 2000ern als leichtgewichtige XML-Alternative für den Datenaustausch zwischen Web-Client und Server entworfen. Es ist streng, minimal und explizit: jeder String gequotet, jedes Objekt in geschweiften Klammern, jedes Array in eckigen Klammern, genau sechs Werttypen (String, Zahl, Objekt, Array, Boolean, null). Keine Kommentare, keine mehrzeiligen Strings ohne Escaping, keine Möglichkeit, einen früher definierten Wert zu referenzieren.

YAML (YAML Ain't Markup Language — ja, rekursiv) kam später und wurde explizit für menschliche Lesbarkeit entworfen. Einrückung statt Verschachtelungszeichen, meist keine Anführungszeichen für Strings, Kommentare mit #, und Anker und Aliase, die erlauben, einen Wert einmal zu definieren und mehrfach zu referenzieren. YAML 1.2 definiert sich als Obermenge von JSON.

In der Praxis ist JSON das Format für maschinelle Kommunikation mit APIs. YAML ist das Format, wenn Menschen Konfigurationen schreiben und pflegen — Einrückung ist schneller zu erfassen als Klammern, Kommentare sind in Konfigurationsdateien unschätzbar.

Wann tatsächlich konvertiert werden muss

CI/CD-Plattformmigration: Verschiedene Plattformen haben unterschiedliche Präferenzen. GitHub Actions nutzt YAML, alte Jenkins-Konfigurationen JSON oder XML. Migration bedeutet Konvertierung der Pipeline-Definitionen.

Kubernetes und REST-APIs: kubectl akzeptiert YAML, die Kubernetes-API selbst arbeitet mit JSON. Skripte direkt gegen die API? JSON. Manifeste für Menschen? YAML.

Konfigurationsdateien und App-Defaults: Viele Anwendungen liefern Standard-Configs als JSON (weil maschinell generiert) und dokumentieren sie als YAML (weil Menschen die Docs lesen).

API-Antworten debuggen: APIs liefern JSON zurück. Eine Antwort inspizieren, bearbeiten und erneut abspielen — in YAML ist das manchmal lesbarer.

Was ein YAML-zu-JSON-Konverter macht

Die Konvertierung hat zwei Schritte: YAML in eine In-Memory-Datenstruktur parsen, dann die Struktur als JSON serialisieren.

YAML-Anker und -Aliase werden aufgelöst: YAML erlaubt es, einen Wert mit &anchor zu definieren und mit *alias zu referenzieren. In JSON gibt es das nicht — der referenzierte Wert wird einfach überall inline wiederholt. Das resultierende JSON ist korrekt, aber ausführlicher.

Typinferenz findet statt: YAML macht implizite Typisierung. Nacktes true wird ein Boolean, 42 eine Integer, 3.14 ein Float. JSON kennt keine Daten und unterscheidet nicht zwischen Int und Float.

Kommentare werden gelöscht: Das ist der schmerzlichste Verlust. Hilfreiche Kommentare, die erklären warum ein Timeout auf 30 Sekunden gesetzt ist oder was ein kryptisches Flag tut — nach der Konvertierung weg. JSON hat keine Kommentarsyntax.

Der YAML-1.1-vs-1.2-Boolean-Albtraum

In YAML 1.1 werden folgende Werte alle als Booleans behandelt:

true, false, yes, no, on, off
TRUE, FALSE, YES, NO, ON, OFF
True, False, Yes, No, On, Off

Das bedeutet, der harmlose YAML-Key aktiviert: yes wird zu "aktiviert": true. Und land: NO — vielleicht ein ISO-Ländercode? — wird zu "land": false.

YAML 1.2 hat das 2009 behoben, indem Booleans auf nur true und false beschränkt wurden. Aber erstaunlich viele YAML-Parser implementieren noch immer 1.1-Regeln.

Die sichere Regel: In jedem YAML, das konvertiert werden könnte, jeden String quoten, der wie ein Boolean aussieht. land: "NO" und aktiviert: "ja", wenn Strings gemeint sind. Das ist die Art Bug, der drei Stunden zur Fehlersuche braucht und fünf Sekunden zur Behebung.

Ist der Roundtrip sicher?

YAML zu JSON zu YAML: Kommentare gehen verloren, Ankerdefinitionen gehen verloren (es entstehen wiederholte Werte), sämtliche Formatierungsentscheidungen im ursprünglichen YAML gehen verloren. Das resultierende YAML ist korrekt, sieht aber maschinell generiert aus.

JSON zu YAML zu JSON: Für Standard-JSON eigentlich sehr sicher. Da JSON ein Subset von YAML ist, bewahrt der Roundtrip alle Daten.

Praktische Konsequenz: Konvertierung für Einweg- oder gleiche Richtungsaufgaben nutzen. Wenn YAML-Konfiguration und JSON-Darstellung parallel gepflegt werden müssen, eine als Wahrheitsquelle behalten und die andere daraus generieren.

Das YAML-zu-JSON-Tool auf ToolboxHubs

Der YAML-zu-JSON-Konverter behandelt all das oben Beschriebene:

1. YAML einfügen — Akzeptiert alles von einfachen Key-Value-Configs bis zu tief verschachtelten Kubernetes-Manifesten.
2. JSON-Ausgabe erscheint sofort — Konvertierung läuft im Browser, nichts wird an einen Server geschickt.
3. Ergebnis kopieren — Kopierbutton drücken, fertig.

Das Tool verarbeitet Anker, mehrzeilige Strings, alle Boolean-Typen, Null-Werte und verschachtelte Strukturen. Es validiert YAML während der Eingabe — bei Einrückungsfehlern oder fehlerhaften Dokumenten erscheint eine Fehlermeldung statt stillschweigend falscher Ausgabe.

Für die Gegenrichtung gibt es den JSON-zu-YAML-Konverter. Gleiche Logik, entgegengesetzte Richtung.

YAML vs. JSON: Die eigenwillige Empfehlung

YAML, wenn Menschen die primären Autoren und Leser sind: Konfigurationsdateien, CI-Pipeline-Definitionen, Kubernetes-Manifeste, Ansible-Playbooks — diese leben im Versionskontrollsystem und werden von Menschen gelesen, überprüft und debuggt. YAMLs Lesbarkeit und Kommentarunterstützung sind echte Vorteile.

JSON, wenn Maschinen die primären Produzenten oder Konsumenten sind: API-Antworten, Datenbankeinträge, generierte Konfigurationen, Datenaustausch zwischen Services — diese profitieren nicht von Lesbarkeit, weil niemand sie von Hand schreibt. JSONs Striktheit und universelle Unterstützung zählen.

An der Grenze — JSON von einer API empfangen, ein YAML-basiertes System konfigurieren oder umgekehrt — ist Konvertierung einfach ein Werkzeug im Workflow. Das Wichtige ist zu verstehen, was sich bei der Konvertierung ändern kann, und darauf zu prüfen, wenn etwas schiefläuft.

Verwandte Tools

YAML-Validator — Vor der Konvertierung prüfen, ob das YAML valide ist.

JSON-Formatierer — Nach der Konvertierung das JSON sauber einrücken.

JSON zu YAML — Die Gegenrichtung. Gleicher Workflow, umgekehrt.

Fazit

YAML und JSON sind beides gute Datenformate, aber für unterschiedliche Situationen. An ihrer Grenze zu arbeiten — Menschen schreiben YAML, Systeme erwarten JSON oder umgekehrt — macht Konvertierung zu einer Routine-Aufgabe.

Der YAML-zu-JSON-Konverter erledigt den mechanischen Teil. Das Verstehen, was bei der Konvertierung verloren geht — Kommentare, Anker, Formatierung — das war das Ziel dieses Artikels.