YAML to JSON Converter
Convert YAML to JSON and JSON to YAML in your browser, with clear errors instead of wrong output.
This YAML to JSON converter turns YAML into JSON and JSON back into YAML, entirely in your browser. Paste a file, pick a tab, and get a result you can copy. It parses the config YAML people actually write: nested mappings, lists, inline flow collections, quoted and plain scalars typed per the YAML 1.2 core schema, and multiline literal and folded blocks. When a file uses something it cannot handle safely, like anchors, aliases, custom tags, or a multi-document stream, you get an error with a line number instead of quietly broken output. Going the other way, it quotes ambiguous strings on purpose so no, on, and version numbers survive every parser.
100% in your browser. Nothing you type ever leaves this page.
YAML to JSON and JSON to YAML, in your browser
Paste YAML, get JSON. Or flip the tab and go the other way. Everything runs locally in your browser, and when a file uses something this converter can't handle safely (anchors, custom tags, multi-document streams), you get a clear error with a line number instead of quietly wrong output. I'd rather annoy you with an error message than hand you mangled config.
Supported: block and inline mappings and lists, quoted and plain scalars typed per the YAML 1.2 core schema, multiline | and > blocks, comments. Rejected with a clear error rather than guessed at: anchors and aliases (& and *), tags (! and !!), multi-document streams (a second ---), directives (%).
Strings that YAML would misread come back quoted on purpose: yes, no, on, off, anything number-shaped, leading zeros like 08540, and values with colons or hashes. Unquoted, a parser would turn them into booleans or numbers behind your back.
What this YAML to JSON converter supports, and what it refuses to guess at
The YAML side of this converter handles the config files people actually write: nested mappings, lists with dashes, inline flow style with curly braces and square brackets, quoted and plain strings, booleans, null, integers and floats typed the way the YAML 1.2 core schema says, plus | literal and > folded blocks. Comments get stripped, like any parser would.
What it deliberately refuses: anchors and aliases (&base, *base), merge keys, custom tags like !!python/object, multi-document streams separated by ---, and YAML directives. Not because they're impossible to implement. Because half-implementing them is worse than nothing. A converter that expands some aliases and silently drops others will burn you exactly once, in production, on a Friday. So you get an error with a line number instead, and you can decide what to do about it.
Duplicate keys also error out here. Most parsers keep one value and toss the other without a word. That silence is where late-night debugging comes from.
The Norway problem and YAML's other famous footguns
yes, no, on, off
The classic. Under YAML 1.1, a list of country codes hits NO for Norway and the parser reads it as the boolean false. Same story for yes, on, off and friends. YAML 1.2 fixed this in its core schema (only true and false are booleans now), and this converter follows 1.2, so your no stays a string when parsing. But here's the thing: you don't control which parser reads your file next. Tons of tooling still behaves like 1.1. That's why the JSON to YAML direction quotes those words defensively. "no" in quotes means no to every parser ever written.
Octals and leading zeros
In YAML 1.1, 0755 was octal, so it parsed as 493. In 1.2 it's decimal 755. Either way it's probably not what you meant if you were writing a file permission, and a US ZIP code like 08540 has the same problem from the other direction. The rule that actually works: if it has a leading zero and it matters, quote it. This tool reads 0o755 and 0x1F as octal and hex per the 1.2 spec, treats plain 0755 as decimal, and quotes leading-zero strings on the way back out.
The tab rule
Tabs are forbidden in YAML indentation. Full stop, no exceptions, and your editor inserting one invisibly is probably the single most common way a previously fine file stops parsing. The converter errors on the exact line so you don't have to squint at whitespace.
When JSON is just the safer format
Honestly, if a file is only ever written and read by programs, use JSON. No indentation semantics, no implicit typing, no Norway problem, and every language parses it identically. YAML earns its risk in exactly one situation: humans editing config by hand, where comments and readability genuinely matter. Comments are YAML's killer feature and JSON's biggest gap, and I don't think that gap is ever getting fixed.
So a pattern I like: keep the human-edited source in YAML, convert to JSON at build or deploy time, and let everything downstream consume the JSON. You get the readable diffs and the comments while people work, and the machines get a format that can't surprise them. This page covers the conversion half of that workflow in both directions.
Sources and further reading
Frequently asked questions
Is this a full YAML 1.2 parser?
No, and it does not pretend to be. It is a pragmatic subset that covers the config YAML you paste every day, with 1.2 core schema typing for scalars. The corners it does not cover (anchors, tags, multi-doc, directives) produce explicit errors instead of wrong output, which is the whole point.
What happens to anchors, aliases and merge keys?
You get an error naming the line and the construct. The converter will not try to expand them, because a half-right expansion is worse than a refusal. Resolve them with your production parser first, then convert the expanded result here.
Why does the converter quote no and on when going from JSON to YAML?
Self-defense. YAML 1.1 parsers, and there are still plenty in the wild, read unquoted no as the boolean false. Norway country code is the famous casualty. Quoting costs two characters and removes the ambiguity for every parser, old or new.
Can I convert a multi-document YAML file?
Not in one go. A second --- marker stops the conversion with a clear error, because JSON has no equivalent of a document stream. Split the file at each --- and convert the documents one at a time.
Does my config leave the browser?
No. Parsing and serializing both happen in your tab, nothing gets posted anywhere. Still, do not paste production secrets into any web page as a habit, this one included, and redact tokens before sharing screenshots.