Why did my YAML value turn into false?

You almost certainly left it unquoted, and YAML 1.1 rules resolved the word to a boolean. `no`, `off`, `n`, `false` and every capitalization of them belong to that set. Wrap the value in single quotes and it stays a string: `country: 'NO'`.

Can I use tabs in YAML?

Not for indentation, which the specification forbids outright. A tab inside a value, in the middle of a line, is fine, but a tab at the start of a line makes the parser fail. Configure your editor to expand tabs to two spaces in YAML files and the problem goes away.

Should I use JSON or YAML?

JSON for APIs and data exchanged between systems, YAML for configuration a person edits. JSON has a small grammar, so parsers behave the same everywhere; the flexibility that makes YAML pleasant to write is the same flexibility that produces the traps in this article.

Can I put comments in a JSON file?

Standard JSON has no comment syntax. YAML supports comments with `#`, and that is one of the most concrete reasons teams pick it for configuration. Comments do not survive conversion to JSON, because there is nothing to convert them into.

Is key order preserved during conversion?

It is preserved here. JSON object keys are walked in insertion order and the YAML output is produced in the same order. Neither specification actually guarantees ordering for objects or mappings, though, so a file that passes through some other tool may legitimately come back reordered.

JSON and YAML Converter - Mustafa Kürşad Başer

Name: JSON and YAML Converter
Author: Mustafa Kürşad Başer

Key Takeaways

Under YAML 1.1 an unquoted no, off, yes, on, y or n parses as a boolean, which is why the country code for Norway, NO, comes back as false.
A version-like 1.10 is read as the float 1.1, and the trailing digit is gone for good.
Indentation is structural in YAML, and tabs are forbidden as indentation; this tool reports a tab with its own error code and line number.
JSON is a subset of YAML 1.2, so every valid JSON file you already have is also a valid YAML file.

The CI file that broke over one unquoted word

A pipeline stopped working one morning, and the only change in the file was two letters added to a list of country codes. The YAML was valid, the linter was quiet, and no error was raised anywhere. The line country: NO had come out of the parser as country: false. This class of bug eats the most time precisely because there is no syntax error to fix: the document parses cleanly, it just does not hold the value you wrote.

The YAML 1.1 boolean trap

YAML 1.1 resolves eight unquoted words to booleans: y, n, yes, no, true, false, on and off. Case does not matter, so NO, No and no all land in the same place. YAML 1.2 narrowed that list to true and false only, but a very large share of deployed parsers (PyYAML, libyaml, js-yaml in its 1.1 mode, and most CI vendors) still apply the old rules.

yaml

1# What you wrote2country: NO3debug: off4deploy: y5 6# What the parser read7country: false8debug: false9deploy: true10 11# What you needed12country: 'NO'13debug: 'off'14deploy: 'y'

Converting JSON to YAML here applies the same rule in reverse: any string that would be re-read as a boolean, a number or null is emitted quoted, and every key that needed it is listed as a warning with the reason. The goal is not only to hand you a correct file but to show where the hazard sits, since you are the one who will edit that file by hand tomorrow.

Warning

Keys follow the same rules as values. The on: block in a GitHub Actions workflow is the well-known case: some parsers read that key as true, and the trigger definition disappears from the document.

Version strings and lost digits

The second family of silent damage is strings that look like numbers. version: 1.10 becomes the float 1.1, and if 1.10 and 1.1 are different releases in your project you are now pointing at the wrong one. id: 007 loses its padding. A value of ~, null or an empty scalar comes back as null rather than as text. YAML 1.1 even resolves sexagesimal notation, which turns 1:30 into the number 90.

Written in YAML	Value read back	Safe form
country: NO	false (boolean)	country: 'NO'
version: 1.10	1.1 (number)	version: '1.10'
id: 007	7 (number)	id: '007'
value: ~	null	value: '~'
time: 1:30	90 (base 60)	time: '1:30'

Values whose type changes when left unquoted. None of these raise an error.

Indentation, tabs and structure

Indentation replaces braces in YAML, so the number of leading spaces defines the structure directly. Tabs are forbidden as indentation, and they fail in the worst possible way: the file looks aligned in your editor while the parser reports a structural problem on some unrelated line. This tool reports tab indentation as its own condition with the line number, because a generic "bad structure" message sends you looking in the wrong place.

YAML also offers two conveniences JSON has no answer for. Comments start with #, which matters a great deal in configuration files. Anchors and aliases let you define a block once (&defaults) and reference it later (*defaults) instead of repeating it. When such a document is converted to JSON the reference is resolved and the content is copied in, so the single definition point does not survive the trip.

Choosing between the two formats

Because JSON is a subset of YAML 1.2, the choice is about audience rather than capability. For data moving between machines, JSON wins: the grammar is small, parsers agree with each other, and support is built into every platform. For configuration a human edits by hand, YAML wins, since you can leave comments and nested structures stay readable without a wall of closing braces.

Frequently Asked Questions

Why did my YAML value turn into false?: You almost certainly left it unquoted, and YAML 1.1 rules resolved the word to a boolean. no, off, n, false and every capitalization of them belong to that set. Wrap the value in single quotes and it stays a string: country: 'NO'.
Can I use tabs in YAML?: Not for indentation, which the specification forbids outright. A tab inside a value, in the middle of a line, is fine, but a tab at the start of a line makes the parser fail. Configure your editor to expand tabs to two spaces in YAML files and the problem goes away.
Should I use JSON or YAML?: JSON for APIs and data exchanged between systems, YAML for configuration a person edits. JSON has a small grammar, so parsers behave the same everywhere; the flexibility that makes YAML pleasant to write is the same flexibility that produces the traps in this article.
Can I put comments in a JSON file?: Standard JSON has no comment syntax. YAML supports comments with #, and that is one of the most concrete reasons teams pick it for configuration. Comments do not survive conversion to JSON, because there is nothing to convert them into.
Is key order preserved during conversion?: It is preserved here. JSON object keys are walked in insertion order and the YAML output is produced in the same order. Neither specification actually guarantees ordering for objects or mappings, though, so a file that passes through some other tool may legitimately come back reordered.