YAML Semantic Difference Checker
Paste a YAML document and see exactly which values would be read differently depending on whether the parser follows YAML 1.1 or YAML 1.2 tag-resolution rules — not a syntax validator, a semantics checker.
Processed locally in your browser. Your file is never uploaded.
How to use this tool
- Paste your YAML, or upload a .yaml/.yml file — nothing leaves your browser.
- Select "Check YAML".
- Review each flagged value: what it means under YAML 1.1, what it means under YAML 1.2, and why that matters.
- Use the suggested portable rewrite, or copy the whole corrected document, to remove the ambiguity.
Assumptions
- Compares the two published schemas literally (YAML 1.1's tag:yaml.org,2002 types vs YAML 1.2's Core Schema) — not any single library's exact behaviour. Real parsers vary: PyYAML's common SafeLoader, for example, applies 1.1-style resolution even when a document declares itself as YAML 1.2.
- Only unquoted (plain) scalars are checked — a value you've already quoted, like "yes", is unambiguous in every schema and is never flagged.
- Recognises `key: value` mappings, including nested ones. Flow-style collections (`{a: 1}`), block scalars (`|`, `>`) and anchors/aliases are out of scope — see Limitations.
Sources & reference data
Methodology
Each plain scalar value in the document is resolved independently under YAML 1.1's tag-resolution regular expressions and YAML 1.2's Core Schema regular expressions. If the two schemas disagree on the resulting type or value, that's flagged. A boolean/null disagreement is marked as likely to break something (it silently inverts truthy/falsy logic); a numeric or timestamp disagreement is marked as worth checking (the value or type changes, but less likely to flip a condition outright).
Worked example
The classic 'Norway problem'
Inputs: country: NO
Result: YAML 1.1 reads NO as boolean false. YAML 1.2 reads it as the string "NO". Flagged as likely to break, with a suggested fix of country: "NO".
A leading-zero number
Inputs: retries: 0123
Result: YAML 1.1 reads 0123 as octal (83). YAML 1.2 reads it as plain decimal (123) — the same text means two different numbers.
Practical guidance
- Quote any value that could be mistaken for a boolean, null or number but is meant to stay a string — country codes (NO, ON), version-ish strings, and yes/no/on/off flags are the most common real-world cases.
- If you control the parser, pin it explicitly to YAML 1.2 Core Schema behaviour rather than relying on a library's historical default.
Common mistakes
- Assuming a YAML file that "looks right" when eyeballed will parse the same way everywhere — the ambiguous cases are specifically the ones that look like plain values.
- Trusting a `%YAML 1.2` directive alone — some popular parsers don't fully honour it and keep 1.1-style scalar resolution regardless.
FAQs
Why does enabled: yes become true?
Under YAML 1.1's boolean word list, "yes" (in any capitalisation) resolves to true. YAML 1.2's Core Schema only recognises true/false as booleans, so under 1.2 the same text stays the string "yes".
What is the YAML Norway problem?
Norway's ISO country code, NO, is also one of YAML 1.1's recognised boolean words for false — so an unquoted country: NO silently becomes country: false under a YAML 1.1 parser.
Does quoting a value always make it safe?
Yes — a quoted scalar ("yes", 'NO') is treated as an explicit string under every YAML schema. This tool never flags an already-quoted value.
Why can PyYAML turn `yes` or `no` into a boolean?
PyYAML's commonly used SafeLoader applies YAML 1.1-style boolean resolution, where plain `yes` is true and `no` is false. For example, `country: NO` can therefore load as a boolean under that schema, while YAML 1.2 Core Schema keeps `NO` as a string. This tool compares published schema rules; it does not execute PyYAML or verify a particular loader configuration.
Last reviewed: 2026-09-25
This is a scalar-resolution checker, not a full YAML parser: flow-style collections, block scalars, anchors/aliases and merge keys aren't analyzed (Tool: YAML Cross-Runtime Preflight covers more of that ground). It also compares the two published schemas, not any specific library's real behaviour, which sometimes differs from the spec (noted above under Assumptions).
Theme and tool preferences, along with saved and recently used lists, are stored only in this browser.