YAML zu JSON umwandeln

Was macht der YAML-zu-JSON-Konverter?

Der Konverter liest YAML 1.2-strict und gibt JSON aus, bidirektional, mit Multi-Document-Support und profil-spezifischen Hinweisen für die wichtigsten 2026er-YAML-Einsatzgebiete: Kubernetes, Docker Compose, GitHub Actions, Helm.

Pure-client. Jede Eingabe bleibt in deinem Browser. Keine Anmeldung, kein Server-Upload, kein Tracking, du kannst das mit den Browser-Dev-Tools im Netzwerk-Tab selbst überprüfen.

Fünf Eigenschaften unterscheiden ihn von Standard-Konvertern:

• YAML-1.2-strict mit Norway-Lint. Der Parser läuft im 1.2-strict-Modus: NO, yes, off bleiben Strings. Der Norway-Lint warnt trotzdem, weil viele Downstream-Parser noch 1.1-Mode fahren.
• Anchor- und Alias-Visualizer. Edge-Liste mit Definitionszeile und allen Verwendungen (*alias und <<-Merge unterschieden), bevor die Auflösung passiert.
• Workflow-Profile. Kubernetes-, Compose-, GHA- und Helm-Validatoren prüfen die Pflichtfelder des jeweiligen Tools, ohne den Konverter zum strengen Linter zu machen.
• Comment-Preservation auf dem Rückweg. JSON → YAML kann optional Kommentare aus einem Original-YAML positions-treu erhalten.
• Typ-Fidelity-Tabelle. Datetime, Binary, Custom-Tags werden unter dem JSON-Output als Liste angezeigt, damit Typ-Verlust nicht versteckt passiert.

Der Konverter ist kein Live-Editor, sondern ein gezielter Format-Brücker zwischen YAML und JSON. Das Schreiben der YAML-Datei selbst geschieht in deinem Editor, VS Code, Vim, Cursor, mit Schema-Validierung und Auto-Complete. Hier kommt die Datei an, wenn sie strukturell fertig ist und nur noch in eine andere Repräsentation übersetzt werden muss.

Was ist der Norway-Bug und wie behandelt das Tool ihn?

Der Norway-Bug ist die meistzitierte YAML-Falle: unter YAML 1.1 parst NO als Boolean false, weil das Token zur 1.1-Bool-Familie gehört (yes/no/on/off, jede Case-Variante). Eine naive Länderliste wie allowed: [DE, FR, NO, ES] wird zu ['DE', 'FR', false, 'ES'], Norwegen verschwindet, ohne dass der Parser einen Fehler meldet.

YAML 1.2 hat dieses Verhalten entfernt; nur true und false sind dort noch Boolean. Aber: viele Parser im Wild laufen bis heute defaulted auf 1.1, weil die Aktualisierung Breaking-Change- Charakter hatte. Python’s PyYAML ist bis Version 6 1.1-default, Ruby’s Psych ebenfalls. Tools wie Norway-Land dokumentieren die Geschichte ausführlich.

Der Lint dieses Konverters scannt die Quelle nach genau diesen Token: NO, Yes, off, oktale Integer mit führender 0 (0755), sexagesimale Werte (22:22). Findet er einen Treffer, zeigt er die Zeile, das Token und einen Konkretvorschlag ("NO" zitiert, 0o755 als ausdrücklicher Oktal-Marker). Das Tool blockiert die Konvertierung nicht, es zeigt nur, wo der 1.1/1.2-Riss durch deinen Code geht.

Wofür sind die Workflow-Profile?

Generische YAML-zu-JSON-Konverter sind Format-Konverter ohne Domänenwissen. Sie wissen nicht, dass ein Kubernetes-Manifest ohne apiVersion und kind vom API-Server abgelehnt wird, oder dass GitHub Actions keine YAML-Anchors auflöst.

Die Profile in diesem Konverter füllen genau diese Lücke:

• Kubernetes: prüft die drei API-Server-Pflichtfelder apiVersion, kind, metadata.name und gibt einen info-level Hinweis aus, wenn ein namespaced Kind (Deployment, Service, …) ohne metadata.namespace aufläuft. Multi-Document-fähig: jede Ressource wird einzeln geprüft.
• Docker Compose: prüft die Existenz von services: (Pflicht), markiert das in Compose v2 überholte version:-Feld als info, akzeptiert x--prefix-Extensions und flag-t unbekannte Top-Level-Schlüssel.
• GitHub Actions: prüft on: und jobs: (Pflicht), gibt eine info-Note für fehlendes name: aus, und warnt bei detected YAML-Anchors, weil Actions sie nicht honoriert.
• Helm: prüft Chart.yaml-Konvention: apiVersion: v2, name, version, type.

Alle Hinweise sind nicht-blockierend. Sie ergänzen die JSON-Ausgabe um Kontext, blockieren sie aber nie. Wer eine strikte Validierung braucht, nutzt kubeval, kustomize, docker compose config, helm lint lokal.

Wie funktioniert der Anchor- und Alias-Visualizer?

YAML-Anchors (&name) und Aliases (*name) sind der DRY-Mechanismus der Sprache. Du definierst ein Stück Konfiguration einmal und verweist mehrfach darauf. << ist der Merge-Key: er merged die Felder der referenzierten Map in die aktuelle Map, mit Override-Möglichkeit.

Das Problem in der Praxis: Sobald eine Datei zwei oder drei Anchors hat, verliert man schnell den Überblick, wo was definiert ist und welcher Override greift. Der Visualizer löst das mit einer kompakten Edge-Liste:

• Jeder Anchor erscheint einmal mit &name und Definitionszeile.
• Darunter steht die Liste aller Verwendungen mit Zeilennummer und Typ-Badge (merge für <<, alias für plain *name).
• Bei einem Eintrag wie defaults: &d und <<: *d in zwei Konfigurationen siehst du auf einen Blick, dass d zweimal als Merge-Source dient.

Der Visualizer scannt die Source textuell, schnell, keine Parser-Vollanalyse nötig. Limit: Anchors in Flow-Style-Sequenzen ([a: &x 1]) werden über mehrere Zeilen nicht erfasst, aber das ist in DevOps-Konfigurationen extrem selten.

Wie funktioniert die Comment-Preservation?

JSON hat per Spec keine Kommentare. Wer YAML → JSON → YAML rückwärts fährt, verliert auf der ersten Strecke alle Kommentare, und sie kommen nicht wieder, weil das JSON nichts davon weiß.

Der Comment-Preservation-Toggle (nur auf dem Rückweg JSON → YAML sichtbar) löst das mit einer zweiten Eingabe: das Original-YAML. Aktiv eingeschaltet:

1. Der Konverter parst das Original-YAML zu einem AST mit Kommentar-Properties auf jedem Knoten.
2. Aus dem JSON wird ein frisches YAML emittiert.
3. Der Konverter walked beide AST-Bäume parallel und überträgt Kommentare per Pfad-Match auf das frische YAML.

Header-Kommentare bleiben Header, Leading-Kommentare bleiben Leading, Trailing-Kommentare hängen wieder hinter dem richtigen Wert. Bei Mappings wird per Key gematcht, bei Sequenzen per Index.

Limit: Wenn du im JSON Keys umbenennst, Felder verschiebst oder Strukturen änderst, fällt der Kommentar an dieser Stelle ab, Pfad-Match findet nichts. Wer Kommentare unbedingt erhalten will, ändert die Daten so, dass die ursprüngliche Struktur erkennbar bleibt.

Was ist absichtlich nicht gebaut?

• Kein YAML-Live-Editor. Der Konverter parst beim Tippen, gibt aber keine Syntax-Vervollständigung und keinen Schema-aware-Auto-Complete. Wer das braucht, nutzt VS Code mit der YAML-Extension.
• Keine Custom-Tag-Erweiterung. !Ref, !GetAtt, !Sub aus CloudFormation oder Ansible-spezifische Tags werden tolerant geparst, aber nicht ausgewertet. Tools wie aws cloudformation validate-template sind die richtige Anlaufstelle.
• Kein Helm-Template-Rendering. Helm-Charts mit {{ .Values.x }}-Platzhaltern erfordern das Helm-Binary. Wir rendern Chart.yaml direkt; values.yaml wird wie generisches YAML behandelt.
• Keine vollständige K8s-Schema-Validierung. Die K8s-Hinweise sind heuristisch. Wer vollständige Validierung gegen das aktuelle Schema braucht, nutzt kubeval oder kustomize build | kubectl --dry-run=server apply.
• Kein Anchor-Auto-Refactoring. DRY-Vorschläge (“hier könntest du einen Anchor extrahieren”) brechen den Refined-Minimalism-Ansatz dieses Tools.

Wo finde ich mehr Details?

• YAML 1.2 Spec, die offizielle Spezifikation
• YAML auf Wikipedia, Geschichte und Eigenschaften
• Norway-Problem Erläuterung, warum 1.2 die impliziten Typen entfernt hat
• Kubernetes-Workflow-Konvention: apiVersion, kind, metadata
• Docker Compose Reference, Compose-Schema
• GitHub Actions Workflow Syntax, Workflow-Reference