- What does 'valid YAML' actually mean?
- YAML is a strict grammar: indentation must be consistent (spaces only, no tabs), mappings need colons followed by a space, flow collections (the [...] and {...} inline forms) must be closed, and strings with special characters must be quoted. 'Valid' here means the document parses cleanly under the YAML 1.2 spec using the JSON-compatible type schema — the same subset Kubernetes manifests, GitHub Actions workflows, and Docker Compose files target. If it parses here, it'll parse in those tools.
- Why does the line number not match my editor?
- It should — we surface 1-based line and column numbers, the same as VS Code, JetBrains, vim, and most other editors. js-yaml internally uses 0-based positions; we add 1 before showing them. If they mismatch, double-check that your editor and the validator are seeing the same content (a trailing newline or a leading BOM can shift things by one line).
- Why are 'yes', 'no', 'on', 'off' treated as strings?
- YAML 1.1 used to coerce them to booleans, which caused the famous 'Norway problem' (the country code NO being read as the boolean false). YAML 1.2 — and the JSON_SCHEMA this validator uses — keeps them as plain strings, matching what Kubernetes, GitHub Actions, Docker Compose, and most other modern parsers do. If you want booleans, write 'true' or 'false' explicitly.
- Does it support multi-document YAML (--- separators)?
- Yes. The validator parses the entire stream and reports how many documents it found. Multi-document YAML is common in Kubernetes manifests (each --- separates a Service, Deployment, ConfigMap, etc.). If any document in the stream is invalid, validation fails with the line and column relative to the start of the input.
- What's the difference between this and a YAML-to-JSON converter?
- Different intent. The converter assumes your YAML is valid and gives you JSON. The validator focuses on telling you whether it's valid in the first place — and if not, where exactly the error is. Use the validator when something downstream (kubectl, GitHub Actions, ansible-playbook) rejects your file and you need to find the bug fast.
- Will the parser catch every kind of error?
- It catches every syntax error — bad indentation, unclosed quotes, dangling flow collections, invalid anchors. It does NOT catch semantic errors against a schema (e.g. 'this Kubernetes Deployment is missing a required field' or 'this GitHub Actions step name is misspelled'). For schema validation, you'd need the destination tool's validator (kubectl --dry-run, actionlint, etc.).
- What about anchors, references, and multi-line strings?
- Fully supported. Anchors (&name) and references (*name) are resolved during parsing; multi-line block scalars (| and >) and their chomping variants (|-, >-, |+, >+) parse to the correct string content. If your anchors or multi-line strings produce an error, it's a real syntax problem — the validator isn't being stricter than the spec.
- Is my YAML uploaded anywhere?
- No. Parsing runs entirely in your browser. Nothing is logged, stored, or sent to a server. You can disconnect the network and the tool still works.
- Why is my file failing on line 1 column 1 even though it looks fine?
- Most often: a UTF-8 byte-order mark (BOM) at the start of the file, or a non-breaking space where you'd expect a regular space, or the document starts with a tab. Save the file as UTF-8 without BOM, and double-check the first line for invisible characters — many editors have a 'show whitespace' or 'render control characters' option that surfaces these.
