YAML Validator: Validate Indentation, Duplicate Keys and Config Structure

A YAML validator should help you avoid deployment surprises

YAML looks friendly because it is readable, but that readability comes with a sharp edge: indentation is data. A list item that moves two spaces can change which service receives an environment variable. A duplicate key may silently replace the earlier value. A tab can pass through a text editor and break a pipeline later. A value that contains a colon can be read differently when it is not quoted. These are small mistakes, but they are exactly the mistakes that make configuration bugs hard to spot in code review.

This YAML validator is built for the files developers and site owners actually paste every day: GitHub Actions workflows, Docker Compose services, Kubernetes manifests, static site front matter and application config snippets. It checks common syntax and structure in your browser, highlights line-level issues, builds a JSON-style preview for normal maps and lists, shows scalar paths and gives profile-specific reminders. It is not a replacement for the exact parser used by Kubernetes, Docker or your CI provider. It is a faster first pass before the real toolchain rejects the file.

How to read the YAML report

Start with the score and the first issue. A clean score means the file passed the practical checks in this page. A warning does not always mean the file is invalid; it may mean the preview cannot safely expand a feature such as anchors or custom tags. The JSON preview is useful for understanding structure, especially when nested lists and maps are hard to scan. The path explorer is better when you need to confirm that a specific value landed under the right parent.

• Indentation checks look for tabs, odd spacing and jumps that often hide a nesting mistake.
• Duplicate key checks watch for repeated keys inside the same simple map scope.
• Scalar detection recognizes booleans, numbers, null, quoted strings and simple inline arrays.
• Profile checks remind you about expected fields for GitHub Actions, Compose, Kubernetes and front matter.
• Path explorer turns nested YAML into concrete paths that are easier to discuss in a ticket.

Practical workflow before committing YAML

Paste the file, choose the closest profile and fix structural warnings first. Then copy the JSON preview only as a review aid, not as a conversion guarantee. After the page looks clean, run the official command for your environment: docker compose config, kubectl apply --dry-run, your CI linter or the static site build. That two-step workflow catches easy mistakes early while still trusting the production parser for the final decision.

Common questions

Is this a full YAML 1.2 parser?

No. It is a practical browser-side validator for common configuration YAML. Full YAML includes anchors, aliases, tags, merge behavior and edge cases that should be validated with a dedicated parser.

Why does duplicate key detection matter?

Some parsers keep the last value and discard the earlier one. That can make a file look correct while the application runs with a different setting than you expected.

Can I paste secrets here?

Avoid pasting production secrets into any online tool. The parsing runs in the browser, but the safer habit is to redact tokens, keys and passwords before screenshots or shared debugging.

Why is YAML so sensitive to indentation?

YAML uses indentation, not braces, to express structure, and it forbids tabs. A single misaligned space changes the meaning or breaks the parse, which is the most common YAML error.

What is the difference between YAML and JSON?

YAML is a superset of JSON aimed at human readability, with comments, anchors and cleaner syntax. JSON is stricter and better for machine interchange. Every JSON file is valid YAML.

Why did my YAML value become true or a number unexpectedly?

YAML auto-types unquoted scalars, so yes, no, on and bare numbers are coerced to booleans or numbers. Quote the value to keep it a string.