YAML to JSON
Anchors, merge keys, block scalars and multiple documents — parsed properly, with line numbers when something is wrong.
A YAML file with several documents separated by --- becomes a JSON array, one entry per document.
Anything the parser had to work around is listed here.
YAML 1.2, which is the version you actually want
There are two YAML specifications in circulation and the difference will bite you. YAML 1.1, from 2005, treats yes, no, on and off as booleans, and reads 12:30 as a base-60 number equal to 750. YAML 1.2, from 2009, dropped both. Most language libraries — PyYAML among them — still implement 1.1, which is why a GitHub Actions workflow parsed by a 1.1 library comes back with a key called True instead of on.
This page follows 1.2. on stays the string on, 12:30 stays the string 12:30, and only true and false are booleans. If you are debugging a config that behaves differently in two tools, this difference is the first thing to check.
The parts of YAML that real files use
Block mappings and sequences, flow collections in {} and [], single and double quoted scalars with escape sequences, comments, and multiple documents separated by --- all work. So do the parts people forget are optional extras:
- Block scalars.
|keeps your line breaks,>folds them into spaces, and the-and+chomping indicators control what happens to the newline at the end. A multi-linerun:step in a CI file is one of these, and getting the trailing newline wrong changes what the shell receives. - Anchors and aliases.
&namemarks a node,*namereuses it. JSON has no equivalent, so the value is simply written out in full at each place it is used. - Merge keys.
<<: *defaultspulls another mapping's keys in, and keys you spell out yourself win over merged ones. This is the backbone of the averagedatabase.yml. - Lists at the same indentation as their key. Both
ports:followed by indented dashes andports:followed by dashes in the same column are legal and both appear constantly in the wild.
What it refuses to guess at
Complex keys written with ?, custom tags beyond the standard !!str, !!int and friends, and plain scalars folded across several lines are not supported. When the parser meets one it stops and tells you the line number, instead of returning a plausible-looking object that is quietly wrong. For a converter, a clear failure beats a silent misreading every time.
Tabs get their own message, because YAML forbids them for indentation and the resulting error from most parsers is famously unhelpful. Duplicate keys are reported too — the later one wins, as it does everywhere, but you are told it happened.
Where JSON simply cannot follow
Three YAML values have no JSON representation. .inf and .nan become null, and the page counts how many times that happened and says so, rather than letting you discover it in production. Dates written unquoted, like 2024-01-31, stay strings here; a 1.1 parser would hand you a date object, and the JSON it produces would differ. Comments are lost, which is unavoidable — JSON has none.
Going the other way
The JSON to YAML direction writes the plainest YAML that round-trips: strings are left unquoted when they cannot be mistaken for a number, a boolean or null, and quoted when they can. A string like "12" or "yes" keeps its quotes, because without them it would read back as something else. Multi-line strings become block scalars. Empty objects and arrays are written as {} and [], which is the only way YAML can express them.
Everything runs in this page, which is the point when the file you are converting is a Kubernetes secret manifest or a CI configuration with deployment keys in it.
Common questions
Why does my GitHub Actions file lose the “on” key in other tools?
Because those tools implement YAML 1.1, where on, off, yes and no are booleans. The key becomes true, and when that is written to JSON you get "true" as a key name. This page follows YAML 1.2, so on stays a string and the file survives the round trip.
Does it handle anchors and aliases?
Yes, including merge keys. &name marks a node, *name reuses it, and <<: *name merges a mapping's keys in. JSON has no way to reference a shared node, so aliased values are written out in full wherever they appear.
My file has several documents separated by ---.
Each one is parsed and the result is a JSON array, one entry per document. A single-document file produces the object or array directly, not an array of one.
What happens to comments?
They are dropped, because JSON has no comments. This is a one-way loss and there is nothing a converter can do about it — keep the YAML as your source of truth.
Why did it fail on a tab character?
YAML forbids tabs for indentation, full stop. It is a common cause of files that look correct and refuse to parse, so the error names the line rather than leaving you to guess.
Are 12:30 and 2024-01-31 converted to numbers and dates?
No. YAML 1.2 treats both as strings, and so does this page. A 1.1 parser reads 12:30 as 750 — twelve times sixty plus thirty — which is one of the more memorable ways a config file can go wrong.
Can I convert JSON back to YAML?
Yes, with the direction switch. Strings that could be misread as numbers, booleans or null are quoted; everything else is left plain. Multi-line strings are written as block scalars.
Is anything uploaded?
No. The parser ships with the page and runs in your tab. That matters here — the YAML people convert is usually infrastructure configuration, and it often has credentials in it.