YAML Validator and Linter

A YAML validator should help you avoid deployment surprises

YAML reads nicely, which is exactly the trap. The readability hides a sharp edge: indentation is data. Nudge a list item two spaces and suddenly a different service gets that environment variable. Repeat a key and one parser quietly throws away the first value. A stray tab slides past your editor and blows up a pipeline three steps later. Drop a colon into an unquoted value and it gets read as something you did not mean. None of these look like much. They are also the precise category of bug that nobody catches in code review, because the file still looks fine.

So this validator is aimed at the files you actually paste all day. GitHub Actions workflows, Compose services, Kubernetes manifests, static site front matter, the odd config snippet you copied from a Stack Overflow answer. It runs the common syntax and structure checks in your browser, flags issues by line, builds a JSON-style preview for ordinary maps and lists, shows you scalar paths, drops in profile-specific reminders. Honestly, I would never call it a stand-in for the real Kubernetes or Docker parser, and I might be wrong about how far you can push it, but as a fast first pass it saves you the embarrassment of CI rejecting something obvious.

How to read the YAML report

Look at the score and the first issue, in that order. A clean score just means the file cleared the practical checks on this page, nothing grander. And a warning is not a verdict that the file is broken. Sometimes it is the preview admitting it cannot safely expand something like an anchor or a custom tag. The JSON preview earns its keep when nested lists and maps get too tangled to read by eye. The path explorer is the one you want when the real question is whether some value actually landed under the parent you thought it did.

• Indentation checks hunt for tabs, weird spacing, and those sudden depth jumps that usually mean a nesting slip.
• Duplicate key checks watch for the same key showing up twice inside one simple map scope.
• Scalar detection reads booleans, numbers, null, quoted strings, the simple inline arrays too.
• Profile checks nudge you about the fields people expect to see for GitHub Actions, Compose, Kubernetes, front matter.
• Path explorer flattens nested YAML into concrete paths, which is just easier when you are trying to describe a problem in a ticket.

Practical workflow before committing YAML

Paste it, pick the closest profile, kill the structural warnings before anything else. Treat the JSON preview as a reading aid only. It is not a promise that your YAML converts cleanly, and please do not ship it as if it were. Once the page looks calm, run whatever your environment actually trusts: docker compose config, kubectl apply --dry-run, your CI linter, the static site build, whichever applies. Two steps. The browser catches the silly stuff up front, the production parser still gets the last word, and that is the part I am not willing to hand over to a tab in a webpage.

Frequently asked questions

Is this a full YAML 1.2 parser?

Nope. It is a practical browser-side validator for the config YAML people write most of the time. The full spec drags in anchors, aliases, tags, merge behavior, a pile of edge cases, and those genuinely belong to a dedicated parser, not this.

Why does duplicate key detection matter?

Here is the sneaky part. Some parsers just keep the last value and toss the first. So the file reads fine to you, and meanwhile the app is quietly running on a setting you never intended. That gap is where the late-night debugging lives.

Can I paste secrets here?

Do not make a habit of pasting production secrets into any online tool, this one included. Yes, the parsing happens in your browser and nothing gets sent anywhere. Still, redact your tokens, keys, passwords before you screenshot or share a debug session. Future you will be glad.

Why is YAML so sensitive to indentation?

Because spaces are the structure. No braces, no brackets, and tabs are flat-out banned. So one space out of place either rewrites what the file means or just refuses to parse. That is the single most common YAML mistake, and it bites everyone at least once.

What is the difference between YAML and JSON?

YAML is basically a superset of JSON built for humans to read: you get comments, anchors, a tidier look. JSON is the stricter one, and it is better when machines are talking to machines. Worth remembering: every JSON file is already valid YAML.