YAML JSON Converter

YAML is a superset of JSON

Every valid JSON document is valid YAML, which is why the conversion from JSON to YAML is always clean. The reverse is lossy in specific ways, because YAML has features JSON simply lacks: comments, anchors and aliases for reuse, multiple documents in one file, and several distinct multi-line string styles. Comments in particular are discarded silently, and in a configuration file the comments are often the most valuable part.

The Norway problem

YAML 1.1 interprets a set of unquoted scalars as booleans: yes, no, on, off, true, false and their capitalised variants. The country code for Norway is NO, so an unquoted list of country codes turns Norway into the boolean false. The same class of bug affects version numbers, where 1.10 becomes the float 1.1 and loses the trailing zero, and MAC addresses or times such as 12:30, which older parsers read as sexagesimal numbers.

The fix is always the same: quote any scalar whose type you care about. If a value must be a string, put it in quotes even when it looks obviously like one.

Indentation is the syntax

YAML uses indentation for structure and forbids tabs entirely, because tab width is ambiguous. A single stray tab produces a parse error that many editors make invisible. Configure your editor to show whitespace and to insert spaces when working with YAML.

Multi-line strings

The literal block style with | preserves newlines; the folded style with > joins lines into a paragraph. Each takes a chomping indicator: a trailing - strips the final newline and + keeps all trailing newlines. Getting this wrong is how a shell script embedded in a CI configuration ends up with its lines concatenated.

Anchors and aliases

An anchor marks a node with &name and an alias reuses it with *name, which avoids repetition in long configurations. JSON has no equivalent, so conversion expands each alias into a full copy. The output is correct but longer, and the relationship between the copies is lost.