Boolean Handling Differences in JSON and YAML
Understand how JSON and YAML handle boolean values differently. Learn about YAML's extended boolean literals (yes/no, on/off) and common conversion gotchas.
Detailed Explanation
Boolean handling is one of the most notorious sources of bugs when converting between JSON and YAML. JSON has exactly two boolean values: true and false. YAML, however, recognizes a much wider set of boolean-like values.
JSON booleans (strict):
{
"enabled": true,
"debug": false
}
YAML equivalent:
enabled: true
debug: false
This is straightforward. But YAML (version 1.1) also treats these as booleans:
| Truthy | Falsy |
|---|---|
true |
false |
True |
False |
TRUE |
FALSE |
yes |
no |
Yes |
No |
YES |
NO |
on |
off |
On |
Off |
ON |
OFF |
The Norway Problem: This is a famous YAML gotcha. Consider a mapping of country codes:
countries:
- code: GB
- code: FR
- code: NO
In YAML 1.1, NO is interpreted as boolean false, not the string "NO". Converting to JSON yields:
{ "countries": [{"code": "GB"}, {"code": "FR"}, {"code": false}] }
The fix -- quote the value:
- code: "NO"
YAML 1.2 (the latest spec) restricts booleans to only true and false (lowercase), which significantly reduces these issues. However, many parsers still default to YAML 1.1 behavior.
When converting JSON to YAML, tools should quote strings like "yes", "no", "on", "off" to prevent them from being misinterpreted as booleans on the round trip.
Use Case
Debugging a CI/CD pipeline where a YAML configuration value like 'on: push' in a GitHub Actions workflow was being parsed as a boolean instead of a string trigger name.