YAML zu JSON

Ja, vollständig. Keine Anmeldung, kein Konto, kein Nutzungslimit und keine Bezahlschranke. Jede Funktion auf dieser Seite steht allen jederzeit zur Verfügung.

Nein. Die Umwandlung läuft per JavaScript in deinem Browser. Dein YAML wird nirgendwohin übertragen — es gibt keinen serverseitigen Endpunkt, kein Logging und keine Analyse der eingefügten Inhalte. Du kannst das prüfen, indem du beim Konvertieren den Netzwerk-Tab öffnest oder die Internetverbindung trennst: Die Seite funktioniert weiter.

Nein. Der Converter läuft im Browser-Tab, den du bereits geöffnet hast — ohne Download, ohne Kommandozeilen-Tool und ohne Erweiterung. Jeder Online-Converter muss entscheiden, wo die Umwandlung stattfindet: Die meisten schicken dein Dokument an ihren Server, dieser behält es auf deinem Rechner. Wenn du lieber ein Skript nutzt, zeigt der Leitfaden „YAML in Code zu JSON umwandeln“ die Varianten für Kommandozeile, Python, Node.js und Go.

Keine künstliche. Die Umwandlung passiert auf deinem eigenen Rechner, die praktische Grenze ist also der Arbeitsspeicher deines Geräts. Dateien mit einigen Megabyte werden problemlos umgewandelt; sehr große Dokumente können die Seite beim Parsen kurz anhalten.

Ja. Nutze den Tauschen-Button zwischen den beiden Bereichen, um die Richtung umzukehren, ohne die Seite zu verlassen, oder gehe zum eigenen JSON-zu-YAML-Converter. Beim Tauschen wird die aktuelle Ausgabe als neue Eingabe übernommen, sodass du ein Dokument hin und zurück wandeln kannst.

Sie werden entfernt, weil JSON keine Syntax für Kommentare hat. Der Converter sagt dir, wie viele entfernt wurden, statt sie stillschweigend zu verwerfen. Wenn du Kommentare behalten musst, nutze den YAML-Formatter, der YAML an Ort und Stelle neu formatiert und sie erhält.

Dateien, die Dokumente mit --- trennen, werden vollständig unterstützt. Du kannst sie als JSON-Array mit allen Dokumenten ausgeben oder als JSON Lines (NDJSON) mit einem kompakten JSON-Objekt pro Zeile — das Format, das kubectl und die meisten Log-Pipelines erwarten. Kubernetes-Manifeste und Helm-Ausgaben bestehen typischerweise aus mehreren Dokumenten.

Ja. Anchors (&name) und Aliases (*name) werden zu ihren vollständigen Werten aufgelöst, weil JSON keine Referenzen ausdrücken kann. Merge Keys (<<) werden standardmäßig aufgelöst, worauf Docker-Compose-, GitLab-CI- und Ansible-Dateien angewiesen sind. Du kannst die Auflösung abschalten, wenn du stattdessen den rohen <<-Schlüssel sehen willst.

YAML 1.2 behandelt unzitierte Werte wie no, yes, on und off als gewöhnliche Strings. YAML 1.1 behandelt sie als Booleans — aus country: no wird also false. YAML 1.1 liest außerdem 022 als Oktalzahl 18 und 12:30 als Zahl 750 zur Basis 60. Dieser Converter verwendet standardmäßig YAML 1.2 und warnt dich, wenn ein Wert in deinem Dokument unter 1.1 anders gelesen würde.

Die beiden häufigsten Ursachen sind ein Tabulator zur Einrückung, den YAML komplett verbietet, und ein unzitierter Wert mit Doppelpunkt, etwa title: foo: bar. Auch nicht geschlossene Klammern und Anführungszeichen erscheinen in den meisten Parsern als Einrückungsfehler; dieser Converter erkennt sie gezielt und zeigt auf das Zeichen, das nie geschlossen wurde.

Ja. Wenn das Dokument nicht geparst werden kann, bekommst du eine verständliche Beschreibung des Problems, die exakte Zeile und Spalte, einen Lösungsvorschlag und eine Markierung in der betroffenen Zeile des Editors. Die eigene Seite YAML-Validator ist dieselbe Engine mit Fokus auf die Diagnose.

Sobald sie geladen ist, ja. Alles, was zum Konvertieren nötig ist, befindet sich bereits in deinem Browser, deshalb funktioniert das Tool weiter, wenn die Verbindung abbricht.

Füge dein YAML in den linken Bereich des Converters oben auf dieser Seite ein — die Umwandlung passiert online im Browser, während du tippst, ohne Button und ohne Upload. Stelle die Einrückung auf 2 Leerzeichen, 4 Leerzeichen, Tabs oder minifiziert, sortiere optional die Schlüssel und kopiere das JSON oder lade es als .json-Datei herunter. Wenn das Dokument nicht geparst werden kann, bekommst du Zeile und Spalte, eine verständliche Erklärung und einen Lösungsvorschlag statt einer leeren Ausgabe. Für wiederholte Umwandlungen erledigt yq -o=json input.yaml dieselbe Aufgabe im Terminal.

Klicke auf Hochladen, um eine .yaml- oder .yml-Datei zu wählen, oder ziehe sie irgendwo auf diese Seite; dann klicke auf Herunterladen, um das Ergebnis als .json-Datei zu speichern. Die Datei wird von deinem Browser gelesen und nirgendwohin gesendet — wichtig bei Konfiguration mit Hostnamen, Registries oder Zugangsdaten. In der Shell: yq -o=json input.yaml > output.json, oder für ein ganzes Verzeichnis: for f in *.yaml; do yq -o=json "$f" > "${f%.yaml}.json"; done

Ja, in fast allen Fällen. YAML 1.2 ist als Obermenge von JSON definiert, und jedes YAML-Dokument aus gewöhnlichen Mappings, Sequenzen, Strings, Zahlen, Booleans und Nulls hat eine exakte JSON-Entsprechung. Vier Dinge überleben den Weg nicht: Kommentare, weil JSON keine Syntax dafür hat; Anchors und Aliases, die zu ihren vollständigen Werten aufgelöst werden, weil JSON keine Referenzen kennt; Mapping-Schlüssel, die keine Strings sind, etwa Datumsangaben; und eigene Tags wie !Ref oder !GetAtt, die außerhalb ihres Werkzeugs keine Bedeutung haben. Dieser Converter meldet jeden dieser Fälle, statt ihn stillschweigend fallen zu lassen.

Umgekehrt: JSON ist gültiges YAML, aber YAML ist im Allgemeinen kein gültiges JSON. Die YAML-1.2-Spezifikation definiert die Sprache als Obermenge von JSON, sodass jedes JSON-Dokument unverändert an einen YAML-1.2-Parser übergeben werden kann — du kannst JSON oben in den YAML-Bereich einfügen, und es wird geparst. Ein YAML-Dokument ist nur dann zufällig gültiges JSON, wenn es im Flow-Stil von JSON geschrieben ist, mit zitierten Schlüsseln und Strings und ohne Kommentare; gewöhnliches, auf Einrückung basierendes YAML wird von jedem JSON-Parser abgelehnt. Die Garantie gilt für YAML 1.2 — YAML 1.1, das PyYAML und ältere Werkzeuge implementieren, ist keine strikte Obermenge von JSON.

JSON ist ein striktes Austauschformat für Maschinen; YAML ist ein Konfigurationsformat für Menschen, das dieselben Daten ausdrücken kann. Konkret: YAML gewinnt seine Struktur aus Einrückung, JSON aus geschweiften und eckigen Klammern; YAML unterstützt Kommentare mit #, JSON gar keine; YAML kann Blöcke über Anchors, Aliases und Merge Keys wiederverwenden, JSON wiederholt jeden Wert vollständig; YAML kann mehrere Dokumente in einer Datei halten, getrennt durch ---, JSON genau einen Wert; und YAML lässt Strings meist unzitiert, was praktisch ist, bis country: NO als false gelesen wird. Weil YAML 1.2 eine Obermenge von JSON ist, kann YAML alles ausdrücken, was JSON kann.

Nutze YAML, wenn ein Mensch die Datei schreibt und pflegt, und JSON, wenn eine Maschine sie schreibt oder liest. YAML zahlt sich bei Konfiguration aus, die im Code-Review gelesen wird — Kubernetes-Manifeste, Docker Compose, GitHub-Actions-Workflows, Ansible-Playbooks, OpenAPI-Spezifikationen —, weil Kommentare Werte erklären und Anchors Wiederholung vermeiden. JSON zahlt sich bei API-Anfragen und -Antworten, Log-Zeilen, Test-Fixtures und allem aus, was in großer Menge erzeugt oder gespeichert wird: Es wird schneller geparst, jede Sprache bringt einen Parser mit, es gibt keine bedeutungstragenden Leerzeichen und keine Versionsdiskussion. Wenn beides zutrifft, lautet die übliche Antwort: in YAML schreiben und beim Build in JSON umwandeln — genau dafür ist der Converter oben auf dieser Seite gedacht.

YAML ist leichter zu lesen und schwerer richtig zu schreiben; JSON ist geschwätziger und deutlich vorhersehbarer. Bei der Lesbarkeit gewinnt YAML bei verschachtelter Konfiguration klar: keine schließenden Klammern, keine Anführungszeichen um jeden Schlüssel, keine Kommas zum Verlegen, und Kommentare für nicht offensichtliche Werte — dasselbe Kubernetes-Manifest ist in YAML rund 40 % kürzer als in JSON. Bei der Handhabung dreht sich das Bild: Einrückung ist bedeutungstragend, ein verirrter Tabulator oder ein falsch ausgerichteter Schlüssel zerstört das Dokument; unzitierte Werte können stillschweigend den Typ wechseln (yes, no, on, off, 022, 12:30); doppelte Schlüssel und die Spaltung zwischen YAML 1.1 und 1.2 erzeugen Dateien, die sauber parsen und trotzdem falsch sind; und YAML-Parserfehler sind berüchtigt vage. JSON hat keinen dieser Fehlermodi — deshalb ist die praktische Empfehlung, YAML zu schreiben und es vor dem Ausliefern zu validieren oder umzuwandeln.