YAML to JSON Converter
Paste block-style YAML below to get JSON — nested mappings, lists,
and scalars are supported; flow-style {a: 1} / [1, 2, 3], anchors, and multi-document files are not
(see the FAQ for why). Nothing you paste is uploaded; conversion
runs entirely in your browser.
A converter that's honest about what it doesn't do
Full YAML 1.2 is a large spec — flow-style inline collections,
anchors and aliases, multi-document streams, multi-line block
scalars, and more. Implementing all of it risks the one thing a
conversion tool should never do: silently producing wrong output
you don't notice until it breaks something downstream. So this
tool deliberately supports only the block-style subset that
covers the overwhelming majority of hand-written config —
nested key: value mappings, --prefixed
lists (whether indented under their key or at the same indent as
it — both are valid YAML), and plain/quoted scalars. If your
input uses flow-style {a: 1} / [1, 2, 3], an anchor (&name), an alias
(*name), a --- multi-document
separator, or a |/> block scalar,
you'll get a clear error naming the line and the feature —
never a silently broken conversion.
Worked example
Input:
name: Alice age: 30 active: true tags: - a - b address: city: Rome zip: "00100"
converts to:
{
"name": "Alice",
"age": 30,
"active": true,
"tags": ["a", "b"],
"address": {
"city": "Rome",
"zip": "00100"
}
}
Notice age becomes the number 30
because it was written unquoted, while zip stays the
string "00100" because it was quoted in the source —
quoting is exactly what tells this parser (and YAML itself) that
a numeric-looking value is text, not a number.
Frequently asked questions
What subset of YAML does this actually support?
Block-style nested mappings (a key followed by indented key: value lines), block-style lists (- items, either at the top level or as the value of a key — indented under the key or at the same indent as the key, both are valid YAML), plain/single/double-quoted scalar values (strings, integers, floats, true/false, null/~), and comments starting with # (a # inside a quoted string is left alone). That covers the vast majority of hand-written config files — Kubernetes manifests, docker-compose.yml, GitHub Actions workflows, app config — without pretending to implement the full YAML 1.2 specification.
What YAML features are NOT supported, and what happens if I paste one?
Flow-style syntax (inline {a: 1} objects or [1, 2, 3] arrays), anchors (&name) and aliases (*name), multi-document files (--- separators), multi-line block scalars (| and >), and non-string map keys are all explicitly out of scope. Rather than guess and risk producing silently wrong JSON, this tool detects those constructs and shows a clear error naming the line and the unsupported feature, so you know exactly what to rewrite instead of getting broken output you might not notice.
Why did my YAML fail with a message about flow-style syntax or an anchor?
Full YAML support (anchors, aliases, flow collections, multi-document streams) is genuinely complex to implement correctly, and a converter that gets it subtly wrong is worse than one that's honest about its limits — a silent bug in a config file conversion can be very hard to spot. If you hit this, the fix is usually mechanical: rewrite {a: 1, b: 2} as two indented key: value lines, or [1, 2, 3] as three - item lines, and re-run the conversion.
How does this handle a value like "00100" that looks like a number?
Exactly as YAML itself would: if the value was written in quotes in your source ("00100"), it's kept as the string "00100" — quoting is what tells YAML (and this parser) that it's text, not a number. If the same value were written unquoted as 00100, it would convert to the number 100, because there's nothing in plain YAML to distinguish a numeric-looking string from an actual number without quotes.
Is my YAML uploaded anywhere?
No. Parsing happens entirely in your browser with a small hand-written parser — nothing you paste is sent to a server, stored, or logged. That's true for every tool on this site.
Does this validate that my YAML is well-formed?
It checks the structure it understands — consistent indentation, matched quotes, and recognizable key: value / - item lines — and reports a line number when something doesn't parse. It isn't a full YAML 1.2 validator, since it only implements the block-style subset described above; a file that's valid YAML but uses an unsupported feature will be rejected with an explanation rather than silently accepted or silently mangled.