Skip to content

Why YAML Turns NO Into false

The Norway problem

Write a list of ISO country codes in YAML and one of them behaves differently from the rest:

countries: [GB, FR, DE, NO, SE] — every entry is the string you wrote, except NO, which the parser reads as the boolean false. YAML 1.1 accepts y, yes, n, no, on, off, true and false as booleans, in any capitalisation, and NO for Norway matches one of them.

The failure is quiet, which is what makes it dangerous. Nothing errors; a downstream lookup simply fails to find a country called 'false' and the entry disappears. The same applies to ON for Ontario and to any single letter Y or N used as a code.

It is not only booleans

Version numbers are the second common trap. `version: 1.2` parses as the number 1.2, while `version: 1.2.3` stays a string, because the second is not a valid number. Two adjacent lines that look identical in style behave differently, and the numeric one loses any trailing zero — 1.10 becomes 1.1, which is a different version entirely.

Leading zeros are a third. A value like 0755 for file permissions may be read as an octal number rather than the string you meant, and a zip code such as 01234 can lose its leading zero and become 1234.

Times are a fourth: `start: 09:30` can be interpreted as a sexagesimal number in YAML 1.1 parsers rather than the string 09:30. Anything that resembles a number, a boolean or a date is a candidate for being reinterpreted.

The fix

Quote anything that is meant to be text and could be read as something else. Quoting is never wrong, even where it is unnecessary, so the safe habit is to quote country codes, version numbers, times, anything with a leading zero, and any single-letter value.

`countries: ['GB', 'FR', 'DE', 'NO', 'SE']` behaves exactly as intended. So does `version: '1.2'`.

The other half of the fix is verification: convert the file to JSON and look at what the values actually became. JSON has no type inference, so a string is unambiguously quoted and a number unambiguously is not — which makes any unintended conversion immediately visible rather than something you discover in production.

Frequently asked questions

Does this affect YAML 1.2 as well?
YAML 1.2 narrowed the boolean set to just true and false, which fixes the Norway problem in principle. In practice many widely used parsers still follow 1.1 behaviour or a hybrid of the two, so relying on the version rather than on quoting is not safe.
Should I use single or double quotes?
Single quotes are literal — the only escape is a doubled single quote. Double quotes process escape sequences such as \n and \t. For a plain value that just needs to stay a string, single quotes are the simpler choice.
Is JSON a safer format for configuration?
It removes this entire category of bug, since JSON has no type inference and every string is explicitly quoted. The trade-off is that JSON has no comments and is considerably more tedious to write by hand, which is exactly why YAML won for configuration in the first place.

Try the YAML to JSON Converter

Convert YAML into JSON or JSON back into YAML, covering nested maps, lists, quoted strings and comments.

Open tool

More guides