YAML Validator

Understanding the Error Output

When validation fails, the error box contains:

• Reason — a plain-English description of what went wrong (e.g., bad indentation, unexpected end of stream).
• Line & Column — the exact position of the error in your input.
• Snippet — the surrounding context from the parser, often showing a caret (^) pointing at the problem character.

Common YAML Syntax Errors

• Inconsistent indentation — YAML requires consistent use of spaces (never tabs) for nesting. Mixing 2-space and 4-space indentation on the same level causes parse errors.
• Missing colon after a key — key value is invalid; it must be key: value.
• Unquoted special characters — characters like :, #, [, ], {, } in values must be quoted or escaped.
• Tab characters — YAML prohibits tabs for indentation. Replace all tabs with spaces.
• Duplicate keys — while some parsers allow them, duplicate keys in the same mapping block are technically invalid YAML 1.2.

Example: Valid YAML

server:
  host: localhost
  port: 8080
  tls: true

database:
  driver: postgres
  name: myapp
  credentials:
    user: admin
    password: "s3cr3t"

allowed_origins:
  - https://example.com
  - https://api.example.com

Example: Invalid YAML (indentation error)

server:
  host: localhost
   port: 8080   # error: extra space causes inconsistent indentation

The validator will report the line and column where the inconsistency is detected, making it easy to locate and fix.

Valid Is Not the Same as Correct

The validator reports syntax errors. YAML that parses can still have the wrong structure, so read the Parsed Structure preview. In this file, carrot lost two spaces of indentation:

fruits:
  - apple
vegetables:
- carrot
  - spinach

The validator says it is valid, and the preview shows "vegetables": ["carrot - spinach"]: the next line was joined to carrot as one string.

YAML 1.1 and YAML 1.2 Read Values Differently

This tool uses js-yaml 4.3.2, which follows YAML 1.2. PyYAML follows YAML 1.1. The same file gives different data:

If a file is read by a YAML 1.1 parser, quote values such as "NO", "yes", and "0777".

Error Messages You Will See

Limits

• Several documents are checked one by one. A file with documents separated by ---, such as a Kubernetes manifest with a Deployment and a Service, is read with js-yaml loadAll. When all are valid, the preview shows a JSON array with one item per document. When one has an error, each document is listed with its line range as valid or with its error, so a broken Service does not hide a valid Deployment.

• Syntax only. The tool does not check a Kubernetes, GitHub Actions, or Docker Compose schema, and it does not apply lint rules. For CI, run yamllint (yamllint .).

• The preview is JSON. Anchors and << merge keys are expanded in the preview, and comments are not shown. Values that JSON cannot show as written are listed above the preview with their JSON Pointer paths; the YAML is still reported as valid. This YAML:

  size: .inf
  id: 9007199254740993
  due: 2026-02-31

  shows The JSON preview does not show these values as written: /size: inf has no JSON form (JSON.stringify would write null); /id: integer 9007199254740993 is outside ±(2^53 − 1), so JavaScript would round it; /due: 2026-02-31 is not a valid date or time. The preview has null, 9007199254740992 and "2026-03-03T00:00:00.000Z" in their place, so do not copy it as the data. The preview writes negative zero as -0.0 and shows timestamps in UTC (2026-10-01T09:30:00+09:00 appears as "2026-10-01T00:30:00.000Z").

• js-yaml work limits. js-yaml 4.3.2 stops a document whose collections are nested more than 100 levels deep, whose merge keys (<<) handle more than 10,000 mappings and keys in total, or that lists more than 100 mappings in one merge key. The error names the limit, for example “collections are nested more than 100 levels deep (the js-yaml default limit)”, with its line and column.