YAML's Norway Problem — Why an Unquoted NO Becomes false
Write debug: yes in a config file and a human reads it as simply "yes." YAML was built with exactly that kind of readability in mind, and it really does auto-convert that line into the boolean true. But that convenience feature trips people up in an unexpected place. A story that's become a running joke in developer communities: someone wrote the unquoted country code NO for Norway into a list of countries, and it got parsed not as a string but as the boolean false — earning the nickname "the Norway Problem." This guide covers why the feature exists, why it eventually became a problem, and which rule this site's own tools actually follow.
1. Why YAML treated no/yes/on/off as booleans in the first place
YAML (YAML Ain't Markup Language) was designed to be a more human-friendly data format than JSON. With the goal that even non-programmers should be able to intuitively edit config files, the YAML 1.1 spec didn't limit booleans to just the pair true/false — it went further and accepted words people actually use in conversation. yes/no, on/off, and y/n, along with their case variants, were all defined as recognized booleans. Writing on and off for a toggle setting reads naturally, so at the time this looked like a practical decision.
2. Why a convenience feature turned into a bug down the line
The problem is that YAML lets the parser decide, on the writer's behalf, "this looks like a boolean to a human, so I'll change its type, not just its value." That rule works fine when the config author actually meant to write a boolean — but it silently corrupts data whenever a string happens to share spelling with one of the boolean candidate words. The classic case is ISO 3166 country codes. Norway's two-letter code is NO, and writing it unquoted in a YAML file of country codes gets it read by the parser not as a string but as the boolean false. Multiple open-source projects have had real bug reports where country-code handling logic mysteriously skipped or misbehaved specifically for Norway, and as that story spread, the name "Norway Problem" stuck.
Input:
country: NOYAML 1.1 parser result:
country → false (boolean)YAML 1.2 parser result:
country → "NO" (string, exactly as intended)The core of the problem is that the exact same line resolves to a completely different value type depending on the parser version. Quote it as
country: "NO" and it's locked in as a string no matter which parser reads it.
3. How YAML 1.2 narrowed this down
The YAML 1.2 spec, revised in 2009, tackled this confusion head-on. It narrowed the core schema's range of strings auto-recognized as booleans down to just true/false (and case variants like True/TRUE), and stopped giving yes/no/on/off any special treatment — they're now left as plain strings. In other words, a parser that follows YAML 1.2 parses country: NO as the plain string "NO." But a spec change doesn't mean every implementation immediately caught up. PyYAML's default loaders (yaml.load, yaml.safe_load), widely used in the Python ecosystem, are known to still operate on YAML 1.1 rules — meaning the same file can be interpreted differently depending on which language or library reads it, something worth keeping in mind in practice at all times.
4. Which rule does this site's tool follow?
This site's YAML-related tools, including the YAML Validator, use the JavaScript library js-yaml 4.x as the parsing engine, and this library follows the YAML 1.2 core schema by default. So if you enter country: NO into this tool and validate it, you'll see it correctly parsed as the string "NO," not the boolean false. That said, this behavior is specific to this site's tools — if a server backend re-reads the same file with a parser that follows YAML 1.1 rules, like PyYAML's default loader, the result can differ. That's why quoting any string that overlaps with a boolean candidate word — country codes, on/off switch values, and the like — is the safest habit, regardless of which parser you're using.
5. Summary — a checklist for writing YAML
- Check for boolean-candidate words: first check whether any string value (country codes, switch names, etc.) overlaps with no, yes, on, off, y, or n.
- Always quote anything ambiguous: wrapping it in quotes, like
country: "NO", locks it in as a string no matter which parser reads it. - Check your parser's version: check the docs for whichever library you're using to see whether it follows YAML 1.1 or 1.2 rules.
- Verify the actual parsed result with a validation tool: before deploying, check the actual parsed structure visually with the YAML Validator.
Frequently Asked Questions
Q. What exactly is YAML's Norway Problem?
A. Under the YAML 1.1 spec, unquoted words like no, yes, on, off, y, and n are automatically interpreted as the booleans true/false. Because of this, writing the ISO 3166 country code NO (Norway) unquoted as country: NO gets parsed not as the string 'NO' but as the boolean false — a well-known bug that came to be called the Norway Problem.
Q. What's the actual difference between YAML 1.1 and 1.2 in boolean handling?
A. YAML 1.1 broadly recognizes y, Y, yes, Yes, YES, n, N, no, No, NO, true, True, TRUE, false, False, FALSE, on, On, ON, off, Off, OFF as booleans. The YAML 1.2 core schema, revised in 2009, narrows that down to only true/false (and case variants) — words like no or on are no longer treated as booleans automatically and remain plain strings.
Q. Which spec version does this site's YAML tool follow?
A. This site's YAML tools, including yaml-validator.html, use the js-yaml 4.x library, which follows the YAML 1.2 core schema by default. So validating country: NO here parses it correctly as the string 'NO', not false.
Q. Why does this issue still come up in practice?
A. Because some widely used parsers, including PyYAML's default loaders (yaml.load, yaml.safe_load), still follow YAML 1.1 rules. Since actual behavior can differ by library, it's a safe habit to always quote values like country codes or on/off strings in YAML regardless of which parser you're using.