YAML-Validator & Linter — Fehler und versteckte Fallstricke finden
Prüfe YAML mit exakter Zeile und Spalte jedes Fehlers und finde die Fehler, die Parser stillschweigend akzeptieren: yes/no-Booleans, Tabs, doppelte Schlüssel.
services:
web:
image: nginx:1.27
ports:
- '8080:80'
- '22:22'
environment:
COUNTRY: 'NO'
DEBUG: 'yes'
APP_VERSION: 1.1
db:
image: postgres:16
restart: unless-stopped
Doppelte Schlüssel: Angezeigt wird jeweils der letzte Wert – genau das, was viele Parser stillschweigend tun. Die formatierte Ansicht wird aus den geparsten Daten neu aufgebaut, Kommentare und Anker bleiben also nicht erhalten. Behebe Probleme in deiner Originaldatei.
Läuft komplett in deinem Browser. Dein YAML wird nie hochgeladen, Secrets in Konfigurationsdateien bleiben also auf deinem Rechner. Alle kostenlosen Tools ansehen.
Ein Problem gefunden oder etwas, das besser sein könnte? Wir lesen jede Nachricht und beheben Fehler schnell.
Dieser kostenlose YAML-Validator prüft eine YAML-Datei auf Syntaxfehler und zeigt die exakte Zeile und Spalte, mit den umgebenden Zeilen und einem Zirkumflex unter dem Problem. Füge ein Kubernetes-Manifest, eine docker-compose.yml, einen GitHub-Actions-Workflow oder eine OpenAPI-Spezifikation ein, und du weißt in einer Sekunde, ob sie geparst wird – und wenn nicht, wo es hakt.
Dass ein Parser deine Datei akzeptiert, heißt nicht, dass sie bedeutet, was du denkst. Der Linter markiert außerdem Werte, die Parser für YAML 1.1 (PyYAML, SnakeYAML, Go yaml.v2) anders lesen als YAML 1.2: NO wird zu false, 0755 zu 493, 22:22 zu 1342 und 1.10 zu 1.1. Er listet jeden doppelten Schlüssel mit beiden Zeilennummern, Tabs in der Einrückung und "key:value" ohne Leerzeichen. Er prüft die Syntax und diese Fallstricke; gegen ein Schema wie die Kubernetes-API validiert er nicht.
So funktioniert’s
- Füge dein YAML in den Editor ein. Geladen ist ein docker-compose-Beispiel mit ein paar absichtlichen Fehlern, damit du siehst, was markiert wird.
- Lies die Statusleiste: Grün heißt gültig, Rot zeigt den Fehler mit Zeile und Spalte und den Zeilen drumherum.
- Klicke auf einen Eintrag in der Lint-Liste, um im Editor zu dieser Zeile zu springen und sie zu korrigieren.
- Wechsle zwischen formatierter YAML- und JSON-Ansicht, um zu prüfen, wie die Datei tatsächlich geparst wurde: Hier werden Überraschungen mit yes/no oder 0755 offensichtlich.
- Kopiere die formatierte Ausgabe oder lade sie herunter, wenn du sie brauchst, und korrigiere weiterhin die Originaldatei, damit Kommentare erhalten bleiben.
Häufige Fragen
Was ist das Norwegen-Problem in YAML?
In YAML 1.1 sind die Wörter y, yes, n, no, on und off ohne Anführungszeichen (in jeder üblichen Schreibweise) Booleans. Eine Liste von Ländercodes, die NO für Norwegen enthält, liefert also false statt des Strings "NO". YAML 1.2 (2009) hat das behoben: Nur true und false sind Booleans. Viele verbreitete Parser folgen aber noch 1.1, darunter PyYAML, Rubys Psych, Javas SnakeYAML und Gos yaml.v2. Die sichere Lösung ist daher, solche Werte in Anführungszeichen zu setzen: "NO", "yes", "on".
Warum sind Tabs in YAML nicht erlaubt?
Die YAML-Spezifikation verbietet Tabs zur Einrückung, weil ihre Breite nicht definiert ist und YAML Struktur über Einrückung ausdrückt. Innerhalb von Werten und Kommentaren sind Tabs erlaubt, nur nicht im führenden Leerraum einer Zeile. Stell deinen Editor so ein, dass er bei .yml- und .yaml-Dateien Leerzeichen einfügt; zwei Leerzeichen pro Ebene sind die verbreitetste Konvention.
Sind doppelte Schlüssel in YAML erlaubt?
Nein. Die YAML-Spezifikation verlangt eindeutige Schlüssel in einem Mapping, aber Parser sind sich uneins, was dann passieren soll: Manche melden einen Fehler (wie dieser Validator), andere behalten stillschweigend den letzten Wert. Das macht Duplikate gefährlich: In einem langen Manifest bearbeitest du vielleicht das erste Vorkommen und siehst keine Wirkung. Dieses Tool listet jedes Duplikat mit der Zeile, in der der Schlüssel zuerst definiert wurde.
Warum meldet mein YAML „bad indentation of a mapping entry“?
Entweder ist die Zeile anders eingerückt als die anderen Schlüssel derselben Ebene, oder ein Wert enthält einen Doppelpunkt mit folgendem Leerzeichen und braucht Anführungszeichen. So scheitert etwa title: Note: read this, weil der Parser einen zweiten Schlüssel sieht. Schreib title: "Note: read this". Prüf die angezeigte Zeile und die darüber; oft beginnt der Fehler in der vorherigen Zeile.
Ist YAML eine Obermenge von JSON?
YAML 1.2 wurde so entworfen, dass gültiges JSON auch gültiges YAML ist, und in der Praxis wird hier jedes JSON-Dokument geparst. Umgekehrt gilt das nicht: YAML ergänzt Kommentare, Anker und Aliase, mehrzeilige Strings und mehrere Dokumente pro Datei. In der JSON-Ansicht siehst du, wie eine YAML-Datei auf einfache JSON-Daten abgebildet wird.
Validiert das Tool Schemas für Kubernetes oder GitHub Actions?
Nein. Es prüft die YAML-Syntax und die genannten Fallstricke, die die meisten echten Fehler verursachen, weiß aber nicht, welche Schlüssel ein Kubernetes-Deployment oder ein GitHub-Workflow erlaubt. Zur Schema-Validierung nutze kubectl apply --dry-run=server, kubeconform oder die YAML-Erweiterung für VS Code mit dem passenden JSON-Schema.
YAML 1.1 vs. YAML 1.2: Werte, die ihre Bedeutung ändern
Dieser Validator parst nach den Regeln von YAML 1.2 (js-yaml). Wird deine Datei von einem Parser für YAML 1.1 gelesen, bedeuten diese Werte ohne Anführungszeichen etwas anderes, und der Linter warnt vor jedem einzelnen:
• yes, no, on, off, y, n → Booleans in 1.1, Strings in 1.2. GitHub-Actions-Workflows beginnen mit on:, was ein 1.1-Parser als Schlüssel true liest.
• 0755 → oktal 493 in 1.1, dezimal 755 in 1.2. Dateirechte und Postleitzahlen mit führender Null sind beide betroffen.
• 22:22 → 1342 in 1.1 (Basis 60), der String "22:22" in 1.2. Die Compose-Dokumentation von Docker empfiehlt genau deshalb, Port-Zuordnungen in Anführungszeichen zu setzen.
• 1.10 → in beiden Versionen die Zahl 1.1. Setze Versionsnummern in Anführungszeichen.
• 2024-01-05 → in den meisten Parsern ein Zeitstempel, kein String.
Die Regel, die alle diese Fälle vermeidet: Setz jeden Wert in Anführungszeichen, der Text sein soll, aber wie etwas anderes aussieht.
Häufige YAML-Fehler und ihre Lösungen
• "bad indentation of a mapping entry": uneinheitliche Einrückung oder ein Wert ohne Anführungszeichen, der ": " enthält.
• "end of the stream or a document separator is expected": meist eine Zeile, die weniger eingerückt ist als ihre Geschwister, oder Text nach einem schließenden Anführungszeichen.
• "can not read a block mapping entry; a multiline key may not be an implicit key": oft ein fehlender Doppelpunkt in der Zeile davor oder ein geöffnetes, aber nicht geschlossenes Anführungszeichen.
• "unexpected end of the stream within a double quoted scalar": ein nicht geschlossenes " irgendwo oberhalb der gemeldeten Zeile.
• Werte, die mit @, `, *, &, !, | oder > beginnen, haben eine besondere Bedeutung oder sind reserviert. Setz sie in Anführungszeichen.
• Ein # mit vorangehendem Leerzeichen beginnt einen Kommentar, password: abc #123 speichert also abc. Setz Werte in Anführungszeichen, die " #" enthalten.
Ähnliche kostenlose Tools
- JSON Formatter — JSON formatieren, minifizieren und validieren, Parse-Fehler mit Zeile und Spalte. Im Browser, ohne Upload.
- JSON in TypeScript — Füge ein JSON-Beispiel ein und erhalte TypeScript-Interfaces, ein Zod-Schema, ein JSON Schema oder Typen für Go, Python, Java, C#, Kotlin, Swift und Rust.
- SQL-Formatierer — Formatiere unordentliches SQL zu lesbaren, einheitlich eingerückten Abfragen für PostgreSQL, MySQL, T-SQL, BigQuery und mehr. Läuft im Browser.
- Regex-Tester — Teste einen regulären Ausdruck an Beispieltext mit Live-Hervorhebung der Treffer, Capture Groups und Vorschau fürs Ersetzen. Kostenlos, im Browser.
- Diff-Checker — Vergleiche zwei Versionen eines Textes, Codes oder einer JSON-Datei und sieh genau, welche Zeilen, Wörter und Zeichen sich geändert haben.