YAML Validator Online: Check Syntax and Lint

This YAML validator checks your YAML syntax online and reports the exact line and column of every error. Paste text, drop a .yml file or load a sample, then review lint warnings and view the result as formatted YAML, JSON or a tree. It is free and needs no sign-in.

What Is YAML and What Does It Mean to Validate It?

YAML is a human-readable data format built from indentation, key-value pairs and lists. It appears in Kubernetes manifests, Docker Compose files, GitHub Actions workflows, CI settings and the frontmatter at the top of Markdown posts. Validating YAML means parsing it the way a real parser would and confirming the text follows the grammar.

Two things trip people up. YAML uses spaces for structure, so one misplaced space can break a file or quietly change its meaning. There are also several versions of the spec. YAML 1.2 is what modern parsers follow, while older tools such as PyYAML and Go yaml.v2 follow YAML 1.1, which reads values like yes, no, on and off as booleans. A file can be valid in both and still mean different things.

How to Validate a YAML File Online

1. Paste your YAML into the YAML input box, drop a .yml file onto it, or load a sample to see how the tool behaves.
2. Open Validation options and choose a Schema: YAML 1.2 Core (the default), YAML 1.2 JSON schema, YAML 1.2 Failsafe or YAML 1.1. Pick the one that matches the parser that will read your file.
3. Leave Validate as I type on, or press Ctrl+Enter to validate right away.
4. Read the banner above the results. It shows the parser verdict: valid or not, with the line and column of the first problem.
5. Filter the findings with All, Errors, Warnings or Info. Press the line number beside a finding to jump to that line in the editor.
6. Switch between the Summary, Formatted YAML, JSON and Tree view tabs to see how your YAML was actually parsed, and adjust Indentation and Line width for long strings to tidy the output.

Worked Example: A Broken Indent and a Hidden Boolean

Say your Compose file has ports: indented three spaces under a service whose other keys use four. The banner turns red and the error points to that line and column, because the key no longer lines up with its siblings. Fix the indent to match, and the banner turns valid.

Now try this input: enabled: yes and mode: 0755. Under YAML 1.1, yes becomes the boolean true and 0755 is read as an octal number (493 in decimal). Under YAML 1.2 Core, yes stays a plain string and 0755 is no longer treated as octal. Check the JSON tab under each schema and you will see the difference. If a Python or Go app reads this file, quote the values ("yes", "0755") so every parser agrees.

How Do You Read Errors, Warnings and Info?

Errors mean the parser could not read the file; warnings and info are lint suggestions that point at common pitfalls. Lint findings never change whether the YAML is valid. The banner always reflects the parser result alone.

Findings marked heuristic are pattern-based guesses and can be wrong, so treat them as prompts to look, not orders. Start with errors, since the parser stops at the first structural problem and later errors can disappear once you fix it. Then scan warnings for items such as duplicate keys, tab characters or values an older parser would read differently.

What Do the Validation Options Do?

Schema

The schema controls how plain values are typed. Core is the modern default. The JSON schema is stricter about types. Failsafe treats every value as a string. YAML 1.1 mimics older parsers. This setting is about value types, not about checking your data against a custom JSON Schema.

Duplicate keys and custom tags

Allow duplicate keys (last one wins) relaxes the duplicate check, which some tools tolerate. Allow custom tags accepts tags such as !Ref, !Sub, !reference and !include, which CloudFormation, GitLab CI and similar formats rely on. Turn it on when you see tag errors in files that work fine in their own ecosystem.

Kubernetes, Docker Compose and GitHub Actions checks

With this option on, the tool recognizes common file types and adds checks for them. A manifest with apiVersion and kind is checked as a Kubernetes resource, for example. These are suggestions layered on top of syntax validation.

Output formatting

For the formatted YAML, choose 2 or 4 spaces, an 80 or 120 character line width or no wrapping, and optionally sort keys alphabetically, quote all strings, expand anchors and aliases, or keep lists at the same column as their key. When a file has several documents separated by ---, the Documents setting can combine all of them into one array.

Who Needs a YAML Checker?

• DevOps engineers catching a bad indent in a Kubernetes manifest before it reaches a cluster.
• Developers debugging a GitHub Actions workflow that fails with a vague parse error.
• Content editors fixing frontmatter that breaks a static site build.
• Backend teams checking how PyYAML or Go will read a config, using the YAML 1.1 schema.
• Learners exploring how YAML maps to JSON through the Tree view.

If you only need to convert between the two formats, the YAML and JSON converter is built for that. For the JSON you produce, the JSON formatter and validator is the natural next step.

Best Practices and Troubleshooting Tips

• Use spaces only. YAML does not allow tabs for indentation, and editors sometimes insert them silently.
• Quote ambiguous values. Version numbers like 1.10, country codes like NO, and file modes should be quoted so they stay strings.
• Fix the first error first. One wrong indent can trigger a chain of later messages.
• Match the schema to the consumer. If the app uses an older library, validate with YAML 1.1; otherwise keep Core.
• Watch colons in text. A value such as note: see: below needs quotes.
• Compare before and after. Paste both versions into the code diff tool to confirm a fix changed only what you intended.
• Check encoded secrets separately. Kubernetes Secret values are Base64, so decode them with the Base64 encode and decode tool if a value looks wrong.

What Are the Limits of This Validator?

A valid result means the syntax parses, not that your application will accept the content. The tool does not know your app's required fields or your custom JSON Schema, and its Kubernetes, Compose and Actions checks cover common mistakes rather than every rule. Heuristic lint findings can be false alarms. Very large documents may show only part of the Tree view, although the formatted YAML and JSON tabs remain available.

Paste your file into the box above to see exactly where it breaks, which schema reads it differently, and what the clean version looks like. For more utilities like this one, browse the web developer tools collection.