Skip to content
ToolBoxGenie

JSON to YAML Converter

Developer Tools · Added 18 August 2026

Turn a JSON payload into readable YAML for a config file, or a YAML config back into JSON for an API. Strings YAML would otherwise misinterpret are quoted automatically, multi-line text becomes a literal block rather than an escaped one-liner, and anything the converter cannot handle is reported with a line number instead of being guessed at.

Direction

Converted in your browser. Paste a real config — it is not uploaded anywhere.

How to use the json to yaml converter

  1. 1Choose the direction: JSON to YAML, or YAML to JSON.
  2. 2Paste your document into the input box.
  3. 3Pick the indentation — two spaces is the near-universal convention for YAML.
  4. 4Press Convert. Parse errors are reported with the line they occur on.
  5. 5Copy or download the result, or convert it back to check the round trip.

Examples

A service config

Input
{ "name": "checkout", "replicas": 3, "env": [{ "name": "LOG_LEVEL", "value": "info" }] }
Result
name: checkout / replicas: 3 / env: with a nested sequence, all in block style

The Norway problem

Input
{ "country": "NO", "enabled": "yes" }
Result
country: 'NO' and enabled: 'yes' — both quoted, because an unquoted YAML 1.1 reader turns them into booleans

YAML back to JSON

Input
A Kubernetes-style manifest with nested maps and sequences
Result
The equivalent JSON, ready to send to an API or diff against another version

About the json to yaml converter

Two formats for two audiences

JSON is a wire format. It is unambiguous, trivially machine-parseable and has exactly one way to write most things — which is why every API speaks it and why nobody enjoys editing it by hand. No comments, mandatory quotes, and a stray trailing comma breaks the file.

YAML is an editing format. It exists because humans maintain configuration files, and it optimises for that: comments, no quotes where none are needed, indentation instead of brackets. The cost is ambiguity — YAML has several ways to write the same thing and several ways for a plain value to be read as something you did not intend.

Where YAML surprises people

Beyond the Norway problem, three things catch people out. Tabs are not valid indentation and produce an error that rarely says so clearly. A version number like 1.10 is a float, and 1.10 equals 1.1 — which is why image tags should always be quoted. And a colon inside an unquoted value ends the key, so a URL or a time can break a line in ways that look fine until they do not.

All three are handled here by quoting on output and by reporting a line number on input. The general lesson holds outside this tool: when a YAML value could be read as something other than a string, quote it.

Round-tripping

Converting JSON to YAML and back should return the document you started with, and that is a genuinely useful check — the 'convert the result back' button exists for it. A value that changes across the round trip has been misread by one direction or the other, and you would rather find that here than in a deployment.

The one thing that does not survive a round trip through JSON is a YAML comment, because JSON has nowhere to put it. If comments matter, edit the YAML rather than regenerating it.

Frequently asked questions

What is the Norway problem?
In YAML 1.1, the unquoted words yes, no, on, off, y and n are booleans. So a list of country codes containing NO silently becomes false. YAML 1.2 narrowed the rule to true and false only, but a great many parsers in production still implement 1.1 — including some widely used ones. This converter quotes any value that could be caught by either version, which costs a pair of quotes and removes the whole class of bug.
Which parts of YAML are supported?
Block mappings and sequences at any depth, flow style ([1, 2] and {a: 1}), plain and quoted scalars, block scalars with | and >, comments, and the usual scalar types. Not supported, and rejected with a clear message rather than mis-parsed: anchors and aliases, custom tags, merge keys, complex keys, and multi-document streams. Ordinary configuration files stay well inside the supported set.
Why reject anchors instead of handling them?
Because JSON has no equivalent. An anchor and alias let one part of a YAML document reference another; expanding them changes the meaning of the file, and dropping them loses data. Reporting them with a line number lets you decide what should happen, which is better than a converter making that decision quietly on your behalf.
Why does my multi-line string come out with a pipe character?
That is a literal block scalar, and it is the readable way to write multi-line text in YAML. The pipe says 'everything indented under this line is the value, newlines included'. A trailing minus means the final newline is stripped. It converts back to exactly the same JSON string, and it is far easier to read and edit than the same text with escaped newlines on one line.
Does YAML preserve the order of keys?
The output preserves the order of the input, and both formats define mappings as unordered, so nothing depends on it. In practice order matters a great deal to humans reading a diff, which is why it is kept rather than sorted.
Can I paste a real production config?
Yes — everything is parsed in your browser and no network request carries your content. That said, a config file with credentials in it is worth treating carefully wherever it is: check what else is in it before you paste it anywhere, here included.

Related tools