Answer: Paste YAML and validate it instantly with line-numbered errors and a formatted preview, all in your browser.
Validate YAML syntax and convert to JSON. Free online YAML parser and validator for configs and manifests.
Validate YAML syntax and convert to JSON. Checks for indentation errors, type mismatches, and structural issues.
YAML is whitespace-sensitive, and that single design decision causes most of the errors people hit. Mixing tabs with spaces is the classic failure: the YAML specification forbids tabs in indentation, so one stray tab character can invalidate an otherwise perfect file. Inconsistent spacing — indenting a sibling key by two spaces in one place and three in another — produces silent structure changes or parse errors instead. Duplicated keys at the same level are rejected by strict parsers but tolerated by lenient ones, which is why a file that loads locally can fail a CI schema check.
Scalar handling trips people up too. A value like version: 1.0 parses as a float, while version: "1.0" stays a string — Kubernetes resource versions are strings, so quoting matters. Unquoted yes, no, on, and off are treated as booleans by the YAML 1.1 spec that most tools implement, even though YAML 1.2 dropped that behavior. Colons inside unquoted values, unescaped @ or backticks at the start of a scalar, and missing spaces after the colon in a mapping are all frequent parse failures in CI pipelines.
Choosing between YAML and JSON is usually about who edits the file. YAML's block style is readable and comment-friendly, which suits hand-edited configs; JSON's strict grammar makes it machine-friendly for APIs. The comparison table below summarizes the practical differences you care about when validating and converting.
| Feature | YAML | JSON |
|---|---|---|
| Comments | Yes (#) | No |
| Multi-line strings | Yes (literal | and folded > blocks) | Escaped \n only |
| Quoting required | Usually optional | Always for strings and keys |
| Trailing commas | Not used in block style | Forbidden |
| Anchors & references | Yes (&anchor / *ref) | No |
| Multiple documents per file | Yes (--- separators) | No (one value per document) |
| Typical use | Configs, K8s manifests, CI pipelines | APIs, data interchange |
Nearly every modern deployment pipeline parses YAML somewhere. Kubernetes manifests define pods, deployments, and services as (often multi-document) YAML files. GitHub Actions workflows live in .github/workflows/*.yml, GitLab CI in .gitlab-ci.yml, and Ansible playbooks, docker-compose files, and OpenAPI specifications are all YAML. Because these files gate deploys, a syntax error costs real time — which is exactly when a fast local validator earns its keep: paste, check, fix, paste back.
Multi-document files deserve special care. A single --- separates documents, and Kubernetes uses this to pack many resources into one manifest. If your file mixes resources with different schemas, validate each document separately; an error in the third document does not stop the first two from being valid.
The cheapest workflow is validation at the moment of editing rather than at the moment of deploying. Paste your YAML here before committing, fix any reported structure errors, and convert to JSON when a tool downstream wants JSON instead. Because this validator runs entirely in your browser, nothing you paste — including any values you would rather not send across the network — ever leaves your machine. For cluster-critical manifests, pair the local syntax check with a server-side schema validation step in CI, since syntax validity and schema compliance are different checks.
A well-formed YAML document has a predictable shape. Mappings use key: value pairs; sequences use dashes; nesting is expressed purely by indentation of two spaces per level by convention. Strings rarely need quotes, numbers and booleans are auto-detected, and null or ~ represent a null value. A comment starts with # and runs to the end of the line. Literal block scalars introduced by | preserve newlines exactly, while folded scalars introduced by > collapse single newlines into spaces — the right choice for long paragraphs and the wrong one for scripts and certificates.
Two more constructs matter in real files. Anchors (&name) attach a label to a node and aliases (*name) reference it later, giving you reuse without copy-paste; merge keys (<<:) pull a mapped anchor's values into another mapping. These are powerful but confuse converters, so if your JSON output looks wrong, check for aliases before assuming a parse bug. Document markers come last: an optional --- starts a document and ... ends one, which is how Kubernetes stacks several resources in a single file.
How do I validate YAML syntax?
Paste your YAML into the input box and click Validate. The tool parses the document and reports either the number of root keys found or the exact syntax error, including indentation and structure problems.
Can tabs be used for indentation in YAML?
No. The YAML specification forbids tab characters in indentation; only spaces are allowed. A single tab can make an entire document fail to parse, so configure your editor to insert spaces when you press Tab.
How do I convert YAML to JSON?
Paste your YAML and click Convert to JSON. The parsed structure is serialized as formatted JSON that you can copy with one click. Nested objects, arrays, booleans, nulls, and numbers all convert to their JSON equivalents.
Is my YAML uploaded to a server?
No. Parsing, validation, and JSON conversion all run locally in your browser with JavaScript. Nothing you paste is transmitted anywhere, making the tool safe for configs that contain credentials or internal hostnames.
Why does my YAML work locally but fail in CI?
Usually a difference in parser strictness: duplicate keys, tab characters, or YAML 1.1-style boolean coercion (yes/no/on/off) can be tolerated by one loader and rejected by another. Validate with the same strictness your pipeline uses and quote ambiguous scalar values.