YAML to JSON Converter

Global tools

The two directions are the same conversation item: a JSON document and the YAML config block that means the same thing. So this page carries both, flipped by one select - paste a config block and get the JSON that goes into an API call, or paste a JSON document and get the YAML that goes into a config file.

The default direction reads YAML. Flip it to build a YAML config block out of JSON.

Paste a whole document and nothing is truncated. The page starts from a small sample you can replace.

How deeply nested blocks are indented in the JSON output.

Leave it blank and the name is built from the side you are on: "formatted.json" or "formatted.yaml".

Results update as you type. Nothing leaves your device.

object to JSON

11 lines

The YAML was read as the subset config files use - maps, sequences and the scalars null, booleans, integers, floats and quoted strings - and everything else was refused by name instead of guessed.

Keys
5
Objects
1
Arrays
1
Depth
3

JSON

{
  "name": "danfio",
  "role": "developer",
  "years": 3,
  "active": true,
  "tags": [
    "TypeScript",
    "SQL",
    "devtools"
  ]
}

Copy it, or download it. One value in, one value out: keys keep their order and nothing is dropped.

What the numbers do not say

  • Anchors (`&name`), aliases (`*name`), custom tags, block scalars (`|` and `>`), flow collections and multi-document files are refused with the line they broke on, because half-read config is worse than a refusal.
  • Unquoted `yes`, `no`, `on` and `off` are read the way config files are read: as the booleans true and false. Quote them ("yes") to keep them as text.
  • A quoted string uses the same escapes as JSON, so a `\n` in the YAML comes through as one string with a newline in it.
Nothing was sent anywhere, and the input was not modified - it was only read and rewritten.

The honesty lives on the YAML side, because YAML is a big language and JSON is a small one. This page reads YAML as the subset config files actually use - maps, sequences and the scalars null, booleans, integers, floats and quoted strings - and refuses anchors, aliases, tags, block scalars, flow collections and multi-document files by name at the line that broke. Half-read config is worse than a refusal, and the page would rather stop and say where than hand you a document that means something else.

About this yaml to json converter

Reading YAML in full takes a whole small language, and this page deliberately does not try to. What it does read is the intersection that configuration files use, typed the way configuration files are typed: `yes`, `no`, `on` and `off` are read as booleans, a number that parses as a number stays a number, and everything outside the intersection is refused with the line it broke on. The result is a converter you can trust with a deployment config, because its answers are reproducible and its limits are printed beside every result.

The other direction is simpler and stronger: everything JSON can hold is a legal YAML value, so nothing is refused except malformed JSON. Keys keep their order, numbers and strings do not change type, and a string that only looks like a number is double-quoted so the trip does not change its meaning. Both directions run entirely in the tab - nothing is uploaded, and the static page already carries a real conversion from the sample so it is useful before anyone has typed.

How this yaml to json converter works

The subset that config files actually use

The reader knows maps (`key: value` and nested blocks), sequences (`- item`), and the scalars null, booleans, integers, floats and double-quoted strings with the standard escapes. Unquoted `yes`, `no`, `on` and `off` are read the way config files are read: as the booleans true and false. A quoted string uses the same escapes as JSON, so a `\n` in the YAML comes through as one string containing a newline.

Anything outside that subset is refused by name rather than guessed at. Anchors (`&name`), aliases (`*name`), custom tags, block scalars (`|` and `>`), flow collections and multi-document files are each named in the refusal, with the line they broke on and a caret under the trouble when there is one.

Why almost-YAML is refused instead of accepted

A converter that accepts almost-YAML feeds almost-YAML into whatever reads the result, and that failure shows up later, in production, far from the tool that caused it. So the page draws a line in advance: the subset above is read, everything else stops the reading with the line and the name of the thing it met. A `|` block scalar is refused with its line and a sentence about quoting or switching to JSON instead - and the refusal is printed rather than buried.

The same discipline protects the output on the JSON side: the document is parsed strictly, and a mistake such as a trailing comma or a single-quoted string is turned into a line, a column, the line itself and a hint, so fixing it is a matter of seconds.

The other direction: JSON to YAML

Everything JSON can hold is a legal YAML value in this subset, so the trip out is simple: parse strictly, then write maps, sequences and scalars with a chosen indent. Nothing is reordered and no value changes type: the YAML says exactly what the JSON said. A number stays a number and a string stays a string, and a string with a leading zero such as `"007"` is not a number in this subset, so it stays text and the trip does not turn it into the number seven.

Keys keep their order, the depth is whatever the data needed, and the result ends with a newline ready to paste into a config block.

The round trip, and what is never claimed

Reading and writing are inverses for every value this page can produce, which we check before release: convert a block to JSON and back and you get the same value, keys in order. But the page claims nothing about YAML it refused - a document with an anchor is refused outright rather than partially read, because the anchor might be referenced later.

Both directions follow a fixed rule applied to the text in the visitor’s browser, and the only files that leave the computer are the ones the visitor downloads on purpose.

Worked examples

Each example below was run through the calculator on this page when the site was built, so the numbers match what you see when you enter the same inputs.

A config block becomes a JSON document

Paste it here: name: danfio role: developer years: 3 active: true tags: - TypeScript - SQL

object to JSON

10 lines

The YAML was read as the subset config files use - maps, sequences and the scalars null, booleans, integers, floats and quoted strings - and everything else was refused by name instead of guessed.

Keys: 5 · Objects: 1 · Arrays: 1 · Depth: 3

The map reads into an object, the sequence into an array, and `3` stays a number.

JSON becomes a config block

Which way: JSON to YAML - a config block out of data · Paste it here: { "name": "danfio", "years": 3, "active": true }

object to YAML

4 lines

A object was parsed strictly and written as YAML in this page's subset - maps, sequences and the scalars null, booleans, numbers and double-quoted strings - so the result is ready to paste into a config block.

Keys: 3 · Objects: 1 · Arrays: 0 · Depth: 2

The same value written as YAML, keys in order.

A string that looks like a number stays a string

Which way: JSON to YAML - a config block out of data · Paste it here: {"code": "007", "n": 7}

object to YAML

3 lines

A object was parsed strictly and written as YAML in this page's subset - maps, sequences and the scalars null, booleans, numbers and double-quoted strings - so the result is ready to paste into a config block.

Keys: 2 · Objects: 1 · Arrays: 0 · Depth: 2

A leading zero is not a number in this subset, so the `"007"` string stays text and the trip does not turn it into seven.

Frequently asked questions

Is my config uploaded anywhere?

No. The conversion follows a fixed rule applied to the text, running in JavaScript in this tab, and the download is a blob created locally. Deployment configs and API responses often contain credentials-adjacent values, so nothing here touches a server at all.

Why are anchors, aliases and tags refused?

Because they are the parts of YAML that make it a small programming language, and reading them halfway produces a document that means something else. This page reads the subset config files actually use and refuses the rest by name, with the line it broke on - half-read config is worse than a refusal.

Are `yes`, `no`, `on` and `off` converted to booleans?

Yes, the way config files read them: unquoted `yes`, `no`, `on` and `off` become true and false. That is the YAML 1.1 convention most tools follow. Quote them - `"yes"` - when you want them kept as text, exactly as you would in a config file.

My YAML uses a `|` block scalar. What happens?

It is refused by name, with the line it broke on and a sentence about what to do - block scalars are outside the subset this page reads. For a multi-line string, use a double-quoted string with `\n` escapes instead, or convert that document with a tool that reads YAML in full.

Will JSON to YAML keep my key order and types?

Yes. Keys keep their order, a number stays a number and a string stays a string, and a string with a leading zero such as `"007"` is not a number in this subset, so it stays text and the trip does not change its meaning. The only choice you make is the indentation.

Assumptions and sources

  • The reader covers the YAML 1.1 subset config files actually use — maps, lists, quoted strings, numbers, booleans — and writes strict JSON per RFC 8259.
  • Anchors, aliases, custom tags and block scalars are refused by name with the line they broke on, because a half-read config is worse than a refusal.
  • Both directions run in your browser; nothing is uploaded.

Last reviewed 2026-10-07. Runs locally on your device; keep backups; no financial advice applies. Read the full disclaimer.

Where a figure on this page comes from an official agency — HUD, IRS, FICO or a state body — the site keeps a dated snapshot of the source page in its sources library, and a scheduled job re-checks that snapshot, so the number can be traced back to the document it came from.