Validate YAML Online

How to Validate YAML Online

1. Paste or Upload Your YAML: Drop a .yaml or .yml file into the input area, or paste content directly into the "Input (YAML)" editor. The validator handles single documents and multi-document files separated by ---.
2. Click Validate: The parser walks the document and reports the first syntax error with line and column, or returns "Valid YAML" if the document is well-formed. No upload, no signup — everything runs in your browser tab.
3. Read the Error Pointer: Errors include a plain-language description (e.g., "mapping values are not allowed here at line 7, column 12") so you can jump straight to the offending character. Common culprits: a tab where a space belongs, a stray colon inside an unquoted scalar, or inconsistent indentation under a list.
4. Fix and Re-Validate: Edit directly in the input pane and click Validate again. Once the document is clean, hit Copy to grab the validated text, or pipe it into YAML to JSON or YAML to XML for the next step in your toolchain.

Why Validate YAML?

YAML's whitespace-sensitive syntax and implicit type coercion make it deceptively easy to break. A single tab character, a value that looks like a boolean (yes, no, on, NO), or a duplicated key can cause Kubernetes to reject a manifest, GitHub Actions to skip a job, or Ansible to set the wrong variable — usually with a cryptic error message that points to the wrong line. Catching these locally before kubectl apply or git push saves minutes of CI churn per attempt.

• Kubernetes manifests — kubectl apply -f deploy.yaml --dry-run=client only checks local syntax and doesn't catch every YAML pitfall before talking to the API server. Validating first surfaces tab/space mistakes and duplicate keys that produce confusing "mapping values are not allowed here" errors from kubectl.
• GitHub Actions, GitLab CI, CircleCI workflows — A misaligned step under jobs.<name>.steps silently runs the wrong action or fails the entire workflow. Validating before commit avoids burning CI minutes on a typo.
• Docker Compose — Service definitions with nested environment, volumes, and depends_on blocks are easy to over-indent. Validating before docker compose up catches structural errors before container start.
• Ansible playbooks and roles — Ansible coerces unquoted yes/no to booleans (it still follows the YAML 1.1 boolean set), so a hostname like no.example.com written unquoted becomes False. The validator flags ambiguous bare scalars.
• Application config (Spring Boot, Rails, Hugo, Helm values) — Production restarts often fail because a config edit slipped a tab in. Validate locally before deploying so the next systemctl restart doesn't crash on parse.
• Schema-conformant data files — OpenAPI specs, GitHub repo metadata (.github/dependabot.yml), and Renovate configs all start as YAML; syntax errors block downstream JSON Schema validation entirely.

YAML 1.1 vs YAML 1.2 — Key Differences

The current spec is YAML 1.2.2 (October 2021), but many parsers in the wild still follow YAML 1.1 semantics. This table summarizes the differences that bite most often:

Notable consequence: PyYAML's safe_load, libyaml, and Ruby's Psych historically defaulted to YAML 1.1 semantics, while Go's gopkg.in/yaml.v3 defaults to 1.2. Validate against the parser your target tool actually uses.

Common YAML Pitfalls

Frequently Asked Questions

Why is my Kubernetes YAML failing with "mapping values are not allowed here"?

That error almost always means a tab character or an unescaped colon inside a string value. kubectl apply --dry-run=client runs a local parse first; if it fails before reaching the API server, the culprit is pure YAML syntax. Paste the manifest into the validator above — it points to the exact line and column, which kubectl usually does not. Common offenders: a tab indenting an env: value, a Docker image tag like image: registry:5000/app that needs quoting, or an annotation value containing a :.

Does the validator support YAML anchors and aliases?

Yes. Anchors (&name) and aliases (*name) are parsed and resolved; the validator flags undefined alias references as errors and detects circular references. Merge keys (<<: *defaults) are accepted as a widely-supported extension even though YAML 1.2.2 removed them from the core spec — most real-world parsers (PyYAML, Ruby Psych, Symfony YAML) still implement them.

Which YAML spec does it validate against?

YAML 1.2.2 (the current revision, published October 2021). Where YAML 1.1 and 1.2 behave differently — bare-word booleans like yes/no/on/off, leading-zero octals — the validator emits a warning so you know your file will be read differently by a YAML 1.1 parser (PyYAML default, libyaml, Ruby Psych default) than by a YAML 1.2 parser (Go yaml.v3, JS js-yaml default).

Why do I need quotes around no, yes, on, and off?

YAML 1.1 promotes those bare words to booleans, so a Norwegian country code written as country: no becomes country: False — the original "Norway problem." YAML 1.2 keeps them as strings, but tools like Ansible, Symfony, and many Helm chart loaders still follow YAML 1.1 boolean rules. Quote anything that could be misread: country: "no", enabled: "yes", port: "8080" if the consumer expects a string.

Can I validate multi-document YAML files?

Yes. The validator handles streams with --- document separators and validates each document independently. Errors are reported with both document index and line number, so a syntax issue in document 3 of a Kustomize bundle is easy to locate. Note that under YAML 1.2, each document is independent — %YAML and %TAG directives no longer carry over from the previous document the way they did in YAML 1.1.

Is this a syntax validator or a schema validator?

Syntax only. The validator confirms your document is well-formed YAML and points out type-coercion ambiguities. It does not check whether the document is a valid Kubernetes Deployment, Helm values.yaml, GitHub Actions workflow, or OpenAPI spec — schema validation requires tool-specific rules (kubectl --validate, helm lint, actionlint, swagger-cli). Syntax validation is the prerequisite: a document that fails here cannot meaningfully be schema-checked.

Does the validator detect duplicate keys?

Yes, and this is one of the highest-value checks. Per the YAML spec, duplicate keys in the same mapping are an error, but most loaders silently keep the last value — meaning a config file with two replicas: lines deploys with whichever came last and discards the other. The validator flags every duplicate with both occurrence line numbers.

Is my YAML sent to a server?

No. Parsing runs entirely in your browser via client-side JavaScript. Nothing is uploaded, logged, or retained — which matters because YAML files routinely contain Kubernetes secret manifests, database connection strings, API tokens in Ansible vault references, and infrastructure topology. For other client-side checkers, see Validate JSON and Validate XML.

What's the file size limit?

Limited by your browser's available memory, not by a server quota. Documents under 5 MB validate instantly on a typical laptop; multi-megabyte Helm values.yaml files or Compose stacks with hundreds of services work too. If a browser tab runs out of memory, split the stream into smaller documents or run yamllint locally.