Using the converter
Paste YAML on the left and read JSON on the right. There are no settings, because YAML has no options worth offering here. Swap the boxes to go the other way.
When something can't be read, the error names the line. That's the whole design. A converter that half-reads a config file and hands back plausible JSON is worse than one that stops and points.
What it reads, and what it refuses
It handles mappings, sequences, nesting by indentation, quoted and bare scalars (also over several lines), comments, flow collections like [a, b] and {a: 1}, and both kinds of block scalar with their chomping indicators.
Anchors and aliases work, and so do merge keys. Write &name before a value and *name anywhere after it, and the JSON gets a full copy at each alias. A <<: *name key pulls in another mapping's keys, the trick docker-compose and CI files use to share settings. Keys you write out yourself win over merged ones. In a list of merges, the earlier maps win.
JSON has no references, so every alias is written out in full. A few nested aliases can stand for billions of values. That's the old billion laughs attack, and the converter stops with an error once the output passes about a million characters. An alias with no anchor before it is an error too. If you meant *.log as text, quote it.
It refuses explicit tags, complex keys and files holding more than one document. Each refusal names the line and says what it found. Guessing would give JSON that looks right and is quietly wrong.
Indentation must be spaces. YAML forbids tabs for indentation outright, which surprises people who have spent a career using them everywhere else.
The Norway problem
YAML 1.1 treated yes, no, on and off as booleans. A list of country codes written in YAML would turn NO into false, and code expecting the string for Norway got a boolean instead.
It isn't the only casualty. A version number like 1.20 reads as the float 1.2. A leading zero means octal, so an ID like 012345 arrives as 5349, and a time like 22:30 is read in base 60 as the integer 1350.
The YAML 1.2 core schema fixed the boolean case by recognising only true and false, and this converter follows it. Paste no on the left and JSON gets the string "no" back. If you want a boolean, write true.
The same schema has no binary numbers, so 0b1 stays a string. It does have .inf and .nan. JSON has no way to write those, so they arrive as the strings "Infinity" and "NaN".
Related conversions
JSON to YAML is the same converter pointed the other way, and it has more to say about why JSON is already valid YAML. XML to JSON covers the older configuration format that YAML mostly replaced.
For a flat table rather than a tree, JSON to CSV is the one you want.
Questions
How do I convert YAML to JSON?
Paste the YAML above and the JSON appears as you type. Nothing is uploaded, so a config file with credentials in it stays on your machine.
Why is "no" a string and not false?
This follows the YAML 1.2 core schema, where only true and false are booleans. YAML 1.1 read no as false, which is how Norway's country code NO used to turn into a boolean.
Does it support anchors and aliases?
Yes. Each alias is replaced by a copy of the value its anchor marked, and `<<` merge keys are expanded with your own keys taking priority. Text inside quotes or a block scalar is never read as an anchor, so a shell line like echo &foo stays as written.
Can I convert a file with several documents in it?
Not in one go. Split it on the --- markers and convert each document separately, or the second document would overwrite the first.
Sources
- YAML 1.2.2 specification: node anchors and alias nodes
- YAML 1.1: Merge key type
- YAML 1.1: Boolean type
- YAML 1.1: Integer type
Added . Last updated and reviewed . What's new






