Paste a YAML file and see instantly whether it parses, with the line and column of every error and an explanation of the likely cause — bad indentation, tabs, unclosed quotes, a colon inside an unquoted value, duplicate keys, or an alias with no anchor. Beyond syntax, lint warnings catch the values that parse differently depending on the tool reading them: the Norway problem (no becoming false), 0755 read as octal, 1:30 read as base-60, and a # that silently turns a color into null.
The JSON preview shows exactly what a YAML 1.2 parser sees, which is the fastest way to spot a value that is not the type you expected. Everything runs in your browser, so secrets in config files stay on your machine. To convert files, use YAML ↔ JSON; for JSON syntax problems, the JSON validator; and to compare two versions of a config, the text diff tool.
Frequently asked questions
What is the YAML "Norway problem"?
In YAML 1.1, unquoted yes, no, on, and off (in any capitalization) are booleans, so a list of country codes containing NO turns Norway into false. YAML 1.2, published in 2009, fixed this: only true and false are booleans. But many widely used parsers still follow 1.1 — PyYAML, Ruby's Psych, SnakeYAML in Java, and Go's yaml.v2 among them — so the same file can mean different things to different programs. This validator parses with YAML 1.2 and warns about every unquoted yes/no/on/off value. Quote them ("NO") and every parser agrees. Keys are not flagged, so GitHub Actions' on: trigger stays quiet.
Why are tabs not allowed in YAML?
YAML uses indentation to express structure, and tabs display at different widths in different editors, so the specification forbids them for indentation entirely. A tab that looks aligned in your editor may be read at a completely different nesting level. Tabs are allowed inside values and in comments, just not as leading indentation. The validator reports tab indentation with the exact line, and most editors can fix a whole file with a "convert indentation to spaces" command. Two spaces per level is the most common convention, used by Kubernetes, GitHub Actions, and Docker Compose.
Why is my value with a colon causing an error?
In YAML a colon followed by a space separates a key from its value. So title: Note: read this is ambiguous — the parser sees Note as the start of a nested key and fails with "Nested mappings are not allowed in compact mappings". The fix is to quote the whole value: title: "Note: read this". A colon without a following space, as in a URL like http://example.com or a time like 10:30, is usually fine unquoted. A related trap is #: a space followed by # starts a comment, so color: #ff0000 gives color an empty value. The validator warns about that case too.
Are duplicate keys an error in YAML?
Yes. The YAML specification requires every key in a mapping to be unique, and strict parsers — including this one, js-yaml, and Go's yaml.v3 — reject files with duplicates. The catch is that PyYAML and some other popular libraries silently accept them and keep the last value, so a duplicated key in a long config file can quietly override the setting you thought you had. This validator reports every duplicate with its line and column, which is especially useful for large Kubernetes manifests, Helm values files, and CI pipelines that have grown by copy and paste.
Does this validate Kubernetes, Docker Compose, or GitHub Actions files?
It validates YAML syntax — indentation, quoting, duplicate keys, anchors and aliases — which is the first thing to check when kubectl, docker compose, or a CI run rejects a file. It also handles multi-document files separated by ---, reporting which document each error is in and showing every document in the JSON preview. What it does not do is check the schema for those tools: it will not tell you that a Deployment is missing spec.selector or that a workflow step uses an unknown key. Custom tags such as CloudFormation's !Ref are reported as warnings and kept as plain values rather than treated as errors.