§
§ · free tool

YAML validator. Live, with JSON view.

Paste YAML. We parse with js-yaml, surface parse errors with line + column, render the equivalent JSON, and run a common-mistake detector for tabs, mixed indentation, missing colons. Browser-only.

Paste YAML. We parse with js-yaml (MIT, ~50KB), surface parse errors with line + column, and render the equivalent JSON so you can verify the type inference. Common-mistake detector flags whitespace and version-string ambiguities even on inputs that parse cleanly.

·
0 chars
JSON equivalent
// JSON appears here once YAML parses
verdict
common-mistake check
Sources used

YAML is parsed in your browser. After the initial library fetch, no network requests carry your content.

Privacy: parsing happens in your browser. Nothing is sent or logged.

§ 02 · YAML gotchas

Five gotchas that bite everyone.

1. The Norway problem. In YAML 1.1, the unquoted string NO parses as the boolean false. So country: NO sets the country field to false, not "Norway." YAML 1.2 fixed this — only literal true / false are booleans. But legacy YAML 1.1 parsers (some Ruby, some PHP) still apply the old rules. Quote any value that could be ambiguous: country: "NO".

2. Tabs are forbidden in indentation. The YAML spec explicitly forbids tabs for indentation. Some parsers accept them anyway; others throw. The detector flags any tab in indentation. Configure your editor to expand tabs to spaces (most modern editors do this automatically when editing .yml files).

3. Numbers with leading zeros parse as octal. version: 010 in YAML 1.1 was octal 8. YAML 1.2 changed this — now requires 0o10 for octal explicitly. But version-shaped strings like 0123 still surprise some parsers. Quote leading-zero numbers if they should stay as strings.

4. Indentation must be consistent within a block. Mix 2-space and 4-space indent in the same nested block and the parser may misalign. The detector flags inconsistent widths. Pick 2 or 4 (most ecosystems prefer 2) and stick with it.

5. Multi-document files use --- separators. A single .yml file can hold multiple documents separated by ---. Common in Kubernetes manifests where one file holds a Service + Deployment + Ingress. The validator handles multi-document files transparently and shows the count. The JSON view renders all documents as an array of objects.

§ 03 · when to use this

Four jobs this tool covers.

Job 1: Pre-commit YAML check. Before pushing a Kubernetes manifest, GitHub Actions workflow, Docker Compose file, or any YAML config — paste here, validate, fix any error or warning. Catches indentation mistakes and Norway-style ambiguities before CI does. Faster than running kubectl apply --dry-run for every iteration.

Job 2: Convert YAML to JSON for a JSON-only consumer. Some downstream system wants JSON but your config is YAML. Paste, validate, copy the JSON view. Useful when an API, a CLI tool, or a library doesn't accept YAML directly. Pair with our JSON Formatter for further transformation of the JSON output.

Job 3: Inspect anchor / alias resolution. When YAML uses anchors (&name) and aliases (*name) for de-duplication, the JSON view resolves them so you can verify the final shape. Common in CI pipelines, deployment manifests, and other configs where a base template gets specialized per environment.

Job 4: Debug a failing CI workflow. When a GitHub Actions / GitLab CI / CircleCI workflow fails with a cryptic YAML parse error, paste the workflow file here. The line + column of the error is usually more accurate than the CI's own error reporting, and the common-mistake detector often surfaces the underlying issue (mixed indent, tab character, missing colon).

§ 04 · questions

Six questions users ask.

Why is YAML so error-prone?

YAML uses indentation to express structure, which means whitespace is semantically meaningful — a single misplaced space changes meaning. Tabs are forbidden by the spec but accepted by some parsers; mixing them with spaces creates ambiguity. Strings without quotes get type-inferred — 'yes' becomes the boolean true, 'NO' becomes false, '01:30' becomes a sexagesimal number. The combination makes YAML harder to author safely than JSON. The validator catches the common gotchas.

What's the JSON view for?

YAML is a superset of JSON — every valid JSON is valid YAML, but the reverse isn't true. The JSON view shows you exactly how the YAML parser interpreted your document. Useful for confirming type inference (was 'yes' parsed as a string or a boolean?), validating against a JSON-Schema downstream, or generating the JSON form for a system that doesn't accept YAML directly. Toggle pretty-print or minified.

What 'common mistakes' does it catch?

Six classes: (1) tab characters in indentation — illegal per spec, accepted by some parsers, breaks others. (2) Mixed indentation widths — 2 spaces in one block, 4 in another; technically allowed but a readability hazard. (3) Unquoted version-shaped strings (1.23.4 reads as a number; 'true'/'false'/'on'/'off'/'yes'/'no' read as booleans). (4) Missing colons after mapping keys. (5) Inconsistent list-item dash spacing. (6) Trailing whitespace at end of lines. Each fires a soft warning with a line number, even if the parse succeeds.

Does it support YAML 1.2?

js-yaml supports YAML 1.2 (the current spec) by default. The historical YAML 1.1 type rules — where 'no' parses as false, 'on' parses as true, '01:30' parses as a number — were removed in 1.2 because they caused the famous 'Norway problem' (NO becoming false). Most modern YAML tooling defaults to 1.2; older configs may rely on 1.1 behavior. If your downstream consumer is strict YAML 1.1, the JSON view here may differ from what they parse — quote ambiguous strings explicitly to be safe.

What about anchors and aliases?

Supported. & defines an anchor (a reusable node), * references it. So a defaults mapping marked as &defaults referenced via prod: <<: *defaults to produce a prod with the merged-in fields. The JSON view resolves all aliases so you see the expanded structure. Watch for circular references — js-yaml will throw an error if it detects them. For complex anchor / alias structures, the JSON view is the easiest way to verify the final shape.

Is the YAML I paste sent anywhere?

No. js-yaml runs entirely client-side. The page is static HTML; the only network request is the initial page load (which fetches js-yaml from jsDelivr CDN). Safe for Kubernetes manifests, GitHub Actions workflows, Docker Compose files, or any sensitive YAML you wouldn't want uploaded.