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 calculator
- 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.
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.