Geht etwas verloren, wenn ich YAML zu JSON konvertiere?

Daten gehen nicht verloren — Skalare, Sequences und Mappings sind in beiden Formaten identisch. Verloren gehen aber Kommentare (JSON kennt keine) und manchmal Anker/Aliases (werden zu duplizierten Objekten expandiert). Behalten Sie die YAML-Quelle für Reviews und Dokumentation.

Was ist das "Norwegen-Problem" in YAML?

In YAML 1.1 wurden no, off, yes, on automatisch zu Booleans — der ISO-Sprachcode für Norwegisch (no) verlor seinen String-Charakter. YAML 1.2 (verwendet von js-yaml@4) hat das korrigiert. In älteren Parsern: language: "no" quoten.

Warum bekomme ich "unexpected tab character" beim Parsen?

YAML erlaubt für Einrückung ausschließlich Spaces. Ein einziger Tab — oft eingeschleust durch Editor-Default oder Copy-Paste aus einem Terminal — bricht den Parse sofort. Konfigurieren Sie Ihren Editor mit expandtab und Width 2, oder lassen Sie yamllint im CI laufen.

Ist es sicher, YAML aus dem Internet zu parsen?

Mit modernen Parsern (js-yaml@4, PyYAML safe_load, SnakeYAML 2.x) ja — diese ignorieren Custom-Tags wie !!python/object/apply. Mit alten Versionen war YAML-Parsing ein RCE-Vektor. Verwenden Sie niemals yaml.load() ohne explicit safe-Modus für untrusted Input.

Wie behandle ich Kommentare beim Roundtrip YAML → JSON → YAML?

JSON kennt keine Kommentare, also gehen sie beim ersten Schritt verloren. Workarounds: ein Pseudo-Key "_comment":"…", JSONC im Konsumenten oder eine Build-Pipeline, die die YAML-Quelle behält und JSON nur als generiertes Artefakt deployt — der gängigste und cleanste Weg.

Werden meine Configs irgendwo gespeichert?

Nein. js-yaml läuft als JavaScript-Bibliothek im Browser; die Konvertierung passiert lokal. CalcSI sieht weder Inhalt noch Größe. Auch beim Copy-Knopf wird die native navigator.clipboard-API genutzt — kein Server-Roundtrip.

YAML ⇄ JSON Konverter

Beide Richtungen, live im Browser, spec-konform

{{ direction === 'yaml2json' ? 'YAML' : 'JSON' }} ({{ __t('input') }})

{{ direction === 'yaml2json' ? 'JSON' : 'YAML' }} ({{ __t('output') }})

YAML oder JSON?

JSON ist kompakter und überall verfügbar, eignet sich gut für APIs und Maschinen. YAML ist leichter zu lesen und zu schreiben (durch Einrückung und Kommentare) und wird bevorzugt für Konfigurationsdateien (Kubernetes, Docker Compose, Ansible, GitHub Actions). Beide repräsentieren dieselben Datentypen — verlustfreie Konvertierung ist also möglich (außer Kommentare gehen bei YAML→JSON verloren).

Häufige Stolperfallen

YAML hat überraschende Spezialfälle: `no` und `off` werden in YAML 1.1 als boolean false interpretiert (norwegisches Sprachkürzel verliert seine Bedeutung). `1.0` ist eine Zahl, `'1.0'` ein String. Zeit-Werte wie `12:00` werden zu Sekunden umgerechnet. Bei einfachen Konfigurationsdateien ist YAML angenehm, bei komplexen Strukturen mit vielen Sonderzeichen ist JSON sicherer.

YAML und JSON im Detail: Specs, Modelle, Konvertierung

JSON (RFC 8259 / ECMA-404) und YAML (YAML 1.2.2, yaml.org) sind syntaktisch sehr unterschiedlich, repräsentieren aber dasselbe Datenmodell: Skalare, Listen (Sequences) und assoziative Arrays (Mappings). YAML ist sogar ein Superset von JSON — jedes gültige JSON ist auch gültiges YAML. Das macht die Konvertierung in beide Richtungen mathematisch verlustfrei für Daten, mit einer wichtigen Ausnahme: Kommentare. YAML erlaubt #-Kommentare, JSON nicht. Beim Weg YAML → JSON gehen Kommentare verloren — bei Configs, die committed werden, sollten Sie die YAML-Quelle behalten.

Praktisch dominieren beide Formate unterschiedliche Bereiche: JSON ist die Lingua Franca für REST/GraphQL-APIs, Logs, Browser-LocalStorage und npm-package.json. YAML ist Standard in Kubernetes-Manifests, Docker Compose, Ansible-Playbooks, GitHub Actions, GitLab CI und MkDocs. Wenn Sie eine deployment.yaml in einem Helm-Chart programmatisch erzeugen, ist der Workflow oft: Daten in TypeScript/Python aufbauen, als JSON in den Build geben und am Schluss YAML produzieren — genau das macht unser Konverter im Browser mit js-yaml@4, einem spec-konformen Parser für YAML 1.2.

Ein entscheidender Punkt für saubere Configs: YAML 1.2.2 hat das berüchtigte "Norwegen-Problem" entschärft. In YAML 1.1 wurden no, NO, off, OFF, yes, on automatisch zu Booleans — der ISO-Code für Norwegisch (no) verlor seine Bedeutung. YAML 1.2 akzeptiert nur noch true und false als Booleans. Wer mit älteren Tools arbeitet (z.B. Ruby Psych 1.x oder Snake YAML 1.x), sollte solche Werte quoten: language: "no".

So konvertieren Sie zwischen YAML und JSON

Die Konvertierung läuft live im Browser. Folgen Sie diesen Schritten:

Wählen Sie die Richtung: YAML → JSON z.B. um eine Kubernetes-Manifest in eine API-Payload zu wandeln, JSON → YAML für menschenlesbare Configs.
Fügen Sie Ihren Quelltext links ein. Achten Sie auf konsistente Einrückung in YAML — nur Spaces, keine Tabs, sonst meldet der Parser "unexpected tab character".
Die Ausgabe erscheint rechts. JSON wird mit zwei Spaces eingerückt; YAML mit zwei Spaces und Zeilenlängenlimit 100 (wrappt lange Strings nicht aggressiv).
Bei Fehlern erscheint die exakte Position unter dem Feld (Zeile/Spalte). Häufigste Ursachen: Tabs statt Spaces, fehlendes :, ungequotete Werte mit Sonderzeichen wie : # @ &.
Kopieren Sie das Ergebnis per Clipboard-Icon. Tipp: für CI-Pipelines können Sie das gleiche js-yaml-Bibliothek-Bundle als Build-Step einsetzen — das Verhalten ist identisch.

Praxisbeispiele

Hier sind typische Konvertierungen, die in der Praxis vorkommen:

Einfache Map: name: Anna\nage: 29 wird zu {"name":"Anna","age":29}. Beachten Sie, dass 29 automatisch als Zahl interpretiert wird.
Liste mit Block-Syntax: roles:\n - editor\n - author wird zu "roles":["editor","author"]. Die Inline-Form roles: [editor, author] liefert dasselbe.
Multi-Line-String: description: |\n Hello\n World bleibt als "Hello\nWorld" mit Newlines erhalten. Mit > würden Newlines zu Spaces umgewandelt.
Kubernetes-Manifest: ein Deployment in YAML mit apiVersion: apps/v1, kind: Deployment und verschachteltem spec.template.spec.containers wird in eine wohlstrukturierte JSON-Struktur transformiert — ideal als API-Body für kubectl --raw.
GitHub-Actions-Workflow: name: CI\non: [push]\njobs: ... wird zu {"name":"CI","on":["push"],"jobs":{...}}. Achtung: hier ist on in YAML 1.1 ein Boolean — js-yaml@4 (YAML 1.2) macht es korrekt zu einem String-Key.

Grenzen, Edge Cases und Sicherheitshinweise

YAML ist mächtig, hat aber Tücken. Erstens: Indentation. YAML kennt nur Spaces, niemals Tabs für Einrückung. Mixed-Indentation oder ein einziger Tab in einem 200-Zeilen-File bricht den ganzen Parse. Setzen Sie Ihren Editor auf expandtab mit Width 2. Zweitens: Anker und Aliases. &name und *name erlauben Wiederverwendung von Strukturen — beim Export zu JSON werden Aliases expandiert (referenzgleiche Substrukturen werden zu zwei separaten Objekten kopiert), wodurch die JSON-Datei deutlich größer wird. Drittens und sicherheitskritisch — YAML-Code-Execution: Frühere YAML-Parser (PyYAML <5, SnakeYAML <2) erlaubten per !!python/object/apply oder !!javax.script.ScriptEngineManager-Tags Remote Code Execution. js-yaml@4 (im Browser) und safe_load (Python) verbieten Custom-Tags per Default — trotzdem sollten Sie YAML aus untrusted source niemals mit dem unsicheren load() parsen. Viertens: Norwegen-Problem. YAML 1.1 macht no → false. js-yaml@4 ist YAML 1.2 und behandelt es korrekt als String — Vorsicht aber, wenn die Konsumenten-Seite YAML 1.1 spricht (manche Cloud-CI-Systeme). Fünftens: Komment-Verlust. YAML → JSON wirft alle #-Kommentare weg. Behalten Sie die YAML-Quelle als Single Source of Truth, JSON nur als Maschinen-Format.

Häufige Fragen zur YAML/JSON-Konvertierung

Geht etwas verloren, wenn ich YAML zu JSON konvertiere?: Daten gehen nicht verloren — Skalare, Sequences und Mappings sind in beiden Formaten identisch. Verloren gehen aber Kommentare (JSON kennt keine) und manchmal Anker/Aliases (werden zu duplizierten Objekten expandiert). Behalten Sie die YAML-Quelle für Reviews und Dokumentation.
Was ist das "Norwegen-Problem" in YAML?: In YAML 1.1 wurden no, off, yes, on automatisch zu Booleans — der ISO-Sprachcode für Norwegisch (no) verlor seinen String-Charakter. YAML 1.2 (verwendet von js-yaml@4) hat das korrigiert. In älteren Parsern: language: "no" quoten.
Warum bekomme ich "unexpected tab character" beim Parsen?: YAML erlaubt für Einrückung ausschließlich Spaces. Ein einziger Tab — oft eingeschleust durch Editor-Default oder Copy-Paste aus einem Terminal — bricht den Parse sofort. Konfigurieren Sie Ihren Editor mit expandtab und Width 2, oder lassen Sie yamllint im CI laufen.
Ist es sicher, YAML aus dem Internet zu parsen?: Mit modernen Parsern (js-yaml@4, PyYAML safe_load, SnakeYAML 2.x) ja — diese ignorieren Custom-Tags wie !!python/object/apply. Mit alten Versionen war YAML-Parsing ein RCE-Vektor. Verwenden Sie niemals yaml.load() ohne explicit safe-Modus für untrusted Input.
Wie behandle ich Kommentare beim Roundtrip YAML → JSON → YAML?: JSON kennt keine Kommentare, also gehen sie beim ersten Schritt verloren. Workarounds: ein Pseudo-Key "_comment":"…", JSONC im Konsumenten oder eine Build-Pipeline, die die YAML-Quelle behält und JSON nur als generiertes Artefakt deployt — der gängigste und cleanste Weg.
Werden meine Configs irgendwo gespeichert?: Nein. js-yaml läuft als JavaScript-Bibliothek im Browser; die Konvertierung passiert lokal. CalcSI sieht weder Inhalt noch Größe. Auch beim Copy-Knopf wird die native navigator.clipboard-API genutzt — kein Server-Roundtrip.