YAML Linter

YAML Linter

YAML linter online free. Check YAML for duplicate keys, indentation issues, trailing spaces. Lint YAML files instantly.

📄

YAML Input

🔍

Lint Results

Enter YAML to lint

Checks Performed

Syntax validation Duplicate keys Tab characters Trailing whitespace Indentation

Features

  • Detect YAML syntax errors with precise line and column numbers
  • Style checks: key ordering, trailing spaces, line length, quote consistency
  • Best-practice warnings: duplicate keys, implicit null values, ambiguous booleans
  • Configurable rule severity (error, warning, info)
  • Real-time feedback as you type
  • Rule explanation with examples for each violation

Common Use Cases

  • Catch configuration errors before deploying to production
  • Enforce coding standards across a team's YAML files
  • Audit third-party YAML files for unexpected patterns
  • Integrate lint checks into CI/CD pipelines
  • Learn YAML best practices through interactive feedback

YAML Linting

Linting is static analysis that checks code for potential errors and style violations without running it. For YAML, this is especially valuable because:

  • Syntax errors are caught immediately — wrong indentation, unclosed quotes, duplicate keys
  • Semantic warnings flag ambiguous values like yes/no (treated as booleans in YAML 1.1 but not YAML 1.2)
  • Style consistency ensures everyone on the team writes YAML the same way

A linter is stricter than a validator: a validator only checks if the YAML parses; a linter also checks if it follows best practices.

Examples

Invalid - Duplicate key (error)
host: localhost
host: 127.0.0.1
Invalid - Ambiguous boolean (warning)
enabled: yes  # "yes" is a bool in YAML 1.1
Valid - Clean YAML
host: localhost
port: 8080
enabled: true

Frequently Asked Questions

What is the difference between YAML 1.1 and 1.2?

YAML 1.1 (used by most older parsers including PyYAML) treats yes, no, on, off, true, false as booleans. YAML 1.2 (stricter, used by newer tools) only recognizes true and false. This means a key with value yes may be parsed as boolean true in one tool and the string "yes" in another. Always use explicit true/false.

Why are duplicate keys a problem?

Most YAML parsers will either throw an error or silently use the last value when encountering duplicate keys. Either way, the result is unpredictable behavior. A linter catches this before it causes a hard-to-debug runtime issue.

How do I suppress a lint warning for a specific line?

Most YAML linters (like yamllint) support inline disable comments, e.g., # yamllint disable-line rule:line-length. Use sparingly — if you find yourself disabling many rules, revisit whether the rule makes sense for your project.

Should I run a linter in CI?

Absolutely. Running yamllint or similar in your CI pipeline blocks merges of malformed or inconsistent YAML before it reaches production. This is especially critical for Kubernetes manifests and CI/CD pipeline definitions.

Related Tools

YAML Formatter

Format and pretty-print YAML

Try it

YAML Validator

Validate YAML syntax

Try it

YAML Diff

Compare two YAML files

Try it

K8s Inspector

Inspect Kubernetes manifests

Try it

💡 Tips

  • Add <code>yamllint</code> to your pre-commit hooks so errors are caught locally before pushing.
  • Create a <code>.yamllint.yml</code> config file at your repo root to share consistent rules across your team.
  • Treat lint warnings as errors in CI — this prevents warning accumulation that teams stop paying attention to.
  • Pay special attention to the "truthy" check: using <code>true</code>/<code>false</code> explicitly instead of <code>yes</code>/<code>no</code> makes your YAML portable across all parsers.