JSON to YAML Converter

Paste JSON or YAML and get the other format instantly. Uses a real YAML parser rather than a hand-rolled one, so multiline strings, nested structures and edge cases come out correct — and rejects duplicate keys instead of quietly picking one.

Both directions, JSON and YAML

Real YAML parser, not a regex approximation

Duplicate-key detection

Line number on parse errors

Runs fully client-side

How to convert between JSON and YAML

Pick a direction

Switch between JSON → YAML and YAML → JSON depending on which one you are starting from.

Paste your document

Conversion runs as you type. A malformed document shows an error with a line number instead of a blank result.

Fix anything flagged

Duplicate keys and syntax errors are reported explicitly rather than silently resolved one way or another.

Copy the result

Copy the converted document. Nothing you paste is stored or sent anywhere.

YAML is a superset of JSON, which is exactly the trap

Every valid JSON document is also valid YAML — the YAML 1.2 spec was deliberately designed that way. This makes people assume conversion is trivial, little more than reformatting braces into indentation. It mostly is, right up until a document uses something JSON has no equivalent for: anchors and aliases (&ref / *ref) for reusing a block, multiline block scalars (| and >, each with different whitespace rules), or YAML's notoriously permissive implicit typing, where an unquoted no, yes, on, off or a bare version-looking string can silently become a boolean or a number instead of the string it looked like.

That gap is why this tool uses a real YAML parser under the hood instead of pattern-matching indentation with regular expressions. A hand-rolled converter tends to work perfectly on every example in its own test suite and then mishandle the first real-world file a visitor pastes in.

Why duplicate keys are treated as an error, not a preference

YAML mappings, like JSON objects, are not supposed to repeat a key. When they do, most lenient parsers quietly keep the last value and discard the earlier one — which means a config file with a typo'd duplicate key silently loses half of what someone intended to configure, with no warning at any point.

This tool rejects duplicate keys outright rather than picking a winner for you. If your input has one, that is very likely a real mistake worth fixing before it reaches whatever reads this file in production — a CI pipeline, a Kubernetes manifest, a docker-compose file.

What gets lost going from YAML to JSON

Comments do not survive. JSON has no comment syntax, so anything after a # in your YAML is gone in the output — there is no format it could go to. If the comments matter, keep the original YAML file as the source of truth and treat the JSON as a generated artifact, not something to hand-edit and convert back.

Anchors and aliases also disappear as a *mechanism* — the tool resolves them and writes out the repeated content in full, because JSON has no way to express "this value equals that other value by reference." The resulting data is identical; only the DRYness of the source YAML is lost in translation.

Why the type coercion story matters when going JSON to YAML

The direction that surprises people least is JSON to YAML: since JSON is a YAML subset, this conversion is close to lossless, and the only real judgment calls are cosmetic — block sequences (- item) versus flow sequences ([item]), and how wide a line can get before it wraps. This tool prefers block style and a 100-character line width, which reads more naturally for a human than the more compact flow style.

A boolean stored as JSON true comes back out as unquoted YAML true — which is exactly the kind of bare word that, if you ever hand-edit that YAML file later and add a new key with an unquoted yes or no, gets reinterpreted as a boolean rather than the string you meant. Quoting string values that could be mistaken for booleans, numbers or null is a defensive habit worth keeping when editing YAML by hand.

Frequently asked questions

Is JSON always valid YAML?

Yes — YAML 1.2 was designed as a strict superset of JSON, so any valid JSON document is automatically valid YAML too, just not idiomatic YAML. The reverse is not true: most real-world YAML uses features, like comments or anchors, that JSON cannot represent at all.

What happens to comments when I convert YAML to JSON?

They are discarded, because JSON has no comment syntax to put them in. This is unavoidable in either direction, so treat the converted JSON as a generated snapshot rather than a file you edit and convert back into the original YAML.

Why did my conversion fail on duplicate keys?

A YAML mapping is not supposed to repeat the same key. This tool rejects it explicitly rather than silently keeping one of the two values, since a duplicate key in a real config file is almost always an accidental typo worth fixing, not an intentional choice.

Does this tool preserve YAML anchors and aliases?

Converting YAML with anchors to JSON resolves them fully — the repeated content is written out in full, since JSON has no reference mechanism. The resulting data is identical to what the anchors expanded to; only the shorthand is lost.

Why does true become a bare word instead of a quoted string in the YAML output?

Because a JSON boolean should stay a boolean in YAML — quoting it would silently turn it into the string "true" instead. The tradeoff is that if you later hand-edit the YAML and add an unquoted yes, no, on or off yourself, YAML's implicit typing will read it as a boolean too, which is worth knowing before it surprises you.

Is my data uploaded anywhere during conversion?

No. Parsing and conversion happen entirely in your browser using JavaScript. Nothing you paste is sent over the network, logged, or stored — closing the tab clears it.

Related tools

Developers

Converter

Output