YAML in JSON konvertieren Online
Konvertiere YAML zu JSON in deinem Browser. Perfekt zur Validierung von Docker-, Kubernetes- oder GitHub-Actions-Konfigurationen.
{
"name": "John Doe",
"age": 30,
"active": true,
"tags": [
"developer",
"javascript"
],
"address": {
"city": "Madrid",
"zip": "28001"
}
}Wofür du es nutzen kannst
YAML zu JSON: DevOps-Konfigurationen sofort validieren
Docker und Kubernetes
Konvertiere docker-compose.yml oder Kubernetes-Manifeste zu JSON, um Strukturen zu validieren oder mit JSON-only-Tools zu verwenden.
CI/CD-Debugging
Validiere GitHub-Actions-Workflows, GitLab-CI-Pipelines oder Ansible-Playbooks durch Konvertierung zu JSON, um die geparste Struktur zu sehen.
100 % privat
Deine YAML-Konfiguration wird in deinem Browser verarbeitet. Verlässt dein Gerät nie. Ideal für Konfigurationen mit Geheimnissen.
Fehlererkennung
YAML-Syntaxfehler (Einrückung, Tabulatoren, ungültige Typen) werden klar vor der Konvertierung angezeigt.
So funktioniert es
Drei Schritte, kein Aufwand
YAML einfügen
Füge deine YAML-Datei ein: docker-compose.yml, Kubernetes-Deployment, GitHub-Actions-Workflow oder eine beliebige YAML-Konfiguration.
Konvertierung und Validierung
Der Konverter parst YAML gemäß der YAML-1.2-Spezifikation und erzeugt sofort gültiges JSON – bei Syntaxfehlern werden diese angezeigt.
Ergebnis-JSON kopieren
Kopiere das formatierte JSON zur Verwendung in deiner API, deinem Konfigurationstool oder zur Validierung der Struktur deines YAML.
FAQ
Noch Fragen?
YAML (YAML Ain't Markup Language, ein rekursives Akronym) ist eine menschenlesbare Datenserialisierungssprache. Die YAML-1.2-Spezifikation wurde im Juli 2009 auf yaml.org veröffentlicht und ist eine Obermenge von JSON: Jedes gültige JSON ist auch gültiges YAML. YAML wird in DevOps-Tool-Konfigurationen weit verbreitet eingesetzt (Docker Compose, Kubernetes, Ansible, Terraform, GitHub Actions, GitLab CI), weil seine einrückungsbasierte Syntax für lange, hierarchische Konfigurationen lesbarer als JSON ist. Anders als JSON unterstützt YAML Kommentare (Zeilen, die mit # beginnen), mehrzeilige Strings, Anker und Aliase zur Wiederverwendung von Daten sowie zusätzliche Datentypen wie ISO-8601-Daten.
YAML bietet zwei mehrzeilige String-Stile. Der wörtliche Stil (mit | markiert) bewahrt Zeilenumbrüche genau so, wie sie geschrieben sind – nützlich für Shell-Skripte, Dateiinhalte oder formatierten Text. Der gefaltete Stil (mit > markiert) wandelt Zeilenumbrüche in Leerzeichen um und bewahrt nur Absatzumbrüche (Leerzeilen) – nützlich für lange Beschreibungen. In JSON werden beide zu Strings mit \n für wörtliche Zeilenumbrüche oder ohne Umbrüche beim gefalteten Stil. Der Chomping-Modifikator (|- für Strip, |+ für Keep) steuert, ob der abschließende Zeilenumbruch erhalten bleibt.
Ja. YAML-Anker und Aliase sind eine Möglichkeit, Knoten im Dokument wiederzuverwenden. In docker-compose.yml ist es üblich, gemeinsame Umgebungsvariablen als Anker zu definieren und sie über mehrere Dienste hinweg mit dem Merge-Key zu referenzieren. Unser Konverter löst alle Anker und Aliase vor der JSON-Generierung auf und erzeugt die vollständige Struktur ohne Referenzen – das korrekte Verhalten, da JSON kein Äquivalent zu YAML-Ankern hat.
Nein. JSON (RFC 7159/RFC 8259) unterstützt keine Kommentare. YAML-Kommentare (Text nach # bis zum Zeilenende) werden beim Parsen verworfen. Das ist eine grundlegende Einschränkung des JSON-Formats, nicht des Konverters. Wenn du Dokumentation zu Konfigurationsfeldern erhalten möchtest, erwäge JSON Schema (das Beschreibungsfelder ermöglicht) oder behalte das ursprüngliche YAML als Quelle der Wahrheit und generiere JSON bei Bedarf.
YAML verwendet Leerzeichen (niemals Tabulatoren) für die Einrückung zur Darstellung der Hierarchie. Die YAML-1.2-Spezifikation legt keine bestimmte Anzahl von Leerzeichen fest, aber die gebräuchlichste Konvention sind 2 Leerzeichen. Konsistenz innerhalb derselben Hierarchieebene ist entscheidend. Das Mischen von Tabulatoren und Leerzeichen ist ein Syntaxfehler in YAML. Der häufigste Fehler ist das versehentliche Mischen von Tabulatoren und Leerzeichen, besonders beim Bearbeiten von YAML in Editoren, die Tabulatoren unterschiedlich expandieren.
Ja. Kubernetes-Manifeste (Deployments, Services, ConfigMaps, Ingress) und docker-compose.yml-Dateien sind Standard-YAML und werden korrekt zu JSON konvertiert. Das ist nützlich zur Validierung der Manifest-Struktur, zur Weitergabe an Tools, die nur JSON akzeptieren (wie einige Kubernetes-API-Clients), oder zum Debuggen unerwarteter Verhaltensweisen durch subtile YAML-Fehler. Die Kubernetes-API akzeptiert sowohl YAML als auch JSON; intern konvertiert kubectl YAML zu JSON, bevor die Anfrage an den API-Server gesendet wird.
YAML zu JSON konvertieren: DevOps- und Kubernetes-Konfigurationsvalidierung im Browser
YAML (YAML Ain't Markup Language) hat sich zum dominanten Konfigurationsformat im modernen DevOps-Ökosystem entwickelt. Docker Compose (eingeführt 2014, jetzt Teil von Docker Engine seit Version 20.10), Kubernetes (dessen API seit dem Google-Launch 2014 Manifeste in YAML oder JSON akzeptiert), GitHub Actions (gestartet November 2019), GitLab CI/CD, Ansible (Red Hat, 2012), Terraform (HashiCorp, 2014) und Helm Charts verwenden alle YAML als primäres Konfigurationsformat. Die YAML-1.2-Spezifikation, auf yaml.org im Juli 2009 veröffentlicht, stellt fest, dass YAML eine strenge Obermenge von JSON ist, was bedeutet, dass jedes JSON-Dokument auch ein gültiges YAML-Dokument ist. Diese Beziehung macht die Konvertierung zwischen den beiden Formaten semantisch verlustfrei: Es gibt keinen strukturellen Informationsverlust, nur Darstellungsunterschiede.
Die Konvertierung von YAML zu JSON ist in mehreren DevOps-Arbeitsabläufen besonders nützlich: Debuggen von CI/CD-Pipelines, bei denen ein Einrückungsfehler unerwartetes Verhalten erzeugt (die JSON-Darstellung macht die Struktur explizit und eindeutig); Verwendung von Tools, die nur JSON als Eingabe akzeptieren (einige Kubernetes-REST-API-Clients, JSON-Schema-Validierungstools oder Prozessoren wie jq, die nativ mit JSON arbeiten); Migration von Konfigurationen zwischen Tools mit unterschiedlichen Formaten; und Validierung, dass YAML wie erwartet geparst wird, besonders bei Verwendung fortgeschrittener Funktionen wie Ankern, Aliassen, Merge-Keys, expliziten Typen oder mehrzeiligen Strings.
Das YAML-Parsing hat einige bekannte Herausforderungen, die zum Begriff Norway-Problem geführt haben: In YAML 1.1 (verwendet von PyYAML vor Version 6.0 und libyaml vor 0.2.5) wurde der Wert NO als boolesches false interpretiert, was dazu führte, dass Norwegens Ländercode NO falsch geparst wurde. YAML 1.2 (die Spezifikation von Juli 2009) hat das behoben: Nur true und false (unabhängig von Groß-/Kleinschreibung) sind Boolesche Werte, und Werte wie yes, no, on, off, die YAML 1.1 als Boolesche Werte behandelte, sind nun Strings. Unser Konverter verwendet eine Bibliothek, die YAML 1.2 implementiert und korrektes, modernes Verhalten garantiert. Für Projekte, die PyYAML verwenden, ist ein Update auf Version 6.0+ (veröffentlicht März 2022) wichtig, da es YAML-1.2-konformen Safe-Loader-Support über yaml.safe_load() hinzufügte.