JSON to YAML

Convert JSON into clean, readable YAML instantly.

JSON Input

or drop a file here

YAML Output

name: zeroserver
private: true
tags:
  - fast
  - client-side
config:
  port: 3000
  ssl: false

From JSON to YAML

YAML is a human-friendly superset of JSON often used for configuration files (Docker Compose, Kubernetes, CI pipelines). This converter parses your JSON and serializes it as YAML with 2-space indentation, preserving nested objects, arrays, and data types. Because YAML is a superset of JSON, any valid JSON can be expressed as YAML. Conversion runs entirely in your browser.

Built and maintained by Meet Shah · Last updated 28 July 2026

What this tool is used for

Turning a JSON config into the YAML a pipeline or a manifest expects.
Making a deeply nested JSON payload readable for review or documentation.
Producing a YAML fixture from a captured API response.
Adding comments to a configuration, which YAML supports and JSON does not.
Comparing two JSON documents more easily by converting both to YAML first.

How it works in practice

A worked example

An API response has to become a config file a human will edit, and the values include a few that YAML treats as special.

Input

{
  "service": "billing",
  "replicas": 3,
  "ports": [8080, 8443],
  "env": { "LOG_LEVEL": "debug", "FEATURE_X": "on" }
}

Output

service: billing
replicas: 3
ports:
  - 8080
  - 8443
env:
  LOG_LEVEL: debug
  FEATURE_X: 'on'

One value came out quoted and the others did not, and the emitter chose that for you. The string on was quoted because a bare on can be read as a boolean under the older schema many tools still use, so writing it unquoted would have produced a file whose meaning depends on which parser opens it. Everything unambiguous is left bare, which is what makes YAML pleasant to read. Long strings are also emitted unfolded on purpose, so a paragraph stays on one line instead of being wrapped into a block scalar.

The edge case that catches people

That folding decision is worth understanding because the default is the other way. Left to itself an emitter wraps a long string across several lines as a folded block, which is valid, means exactly the same thing, and rewrites every line of the file — so a config regenerated with a different width produces a diff that touches everything and shows nothing. Disabling the width is what keeps the output stable, and it is the setting to look for in whatever library you use next.

When not to use this tool

The output is data and a config file is usually more than data. Nothing here can invent the scaffolding a real manifest needs, and nothing here writes the comment that explains why a value is what it is — which in a config is often the most important line in the file. Key order is also preserved from the JSON rather than arranged for a reader, so a generated file tends to put the interesting settings wherever the API happened to emit them. Convert to get the shape right, then edit it as a document.

Frequently Asked Questions

Is every JSON file valid YAML?: Under YAML 1.2, yes — it is a strict superset, so JSON can be pasted directly. Under YAML 1.1, which many parsers still implement, some JSON edge cases differ. The conversion direction is therefore the safe one.
What does converting to YAML gain?: Comments, which JSON has no syntax for at all, plus multi-line strings via block scalars and anchors for reuse. For configuration those are the reasons to convert; for data interchange JSON's lack of ambiguity is the advantage.
Which keys need quoting after conversion?: Any that would be coerced: yes, no, on, off, true, false, null and the empty string. A JSON key of "no" becomes an unquoted YAML key that parses as boolean false in YAML 1.1 — the Norway problem, arriving through conversion.
How are long strings handled?: Best as block scalars — | to preserve newlines, > to fold them. A JSON string containing \n becomes a literal escape in YAML unless converted to a block, which is technically correct but defeats the readability YAML is chosen for.
Is the conversion lossless?: In this direction essentially yes, since YAML can express everything JSON can. It is the return trip that loses things — comments, anchors and multiple documents per file have no JSON equivalent.
Which strings must be quoted after conversion?: Anything YAML would otherwise interpret — `yes`, `no`, `on`, `off`, `null`, `~`, a leading zero, or a value containing a colon-space. A converter that quotes only when strictly necessary produces a file where one of these eventually bites.

Common errors and gotchas

Letting a string be emitted unquoted where YAML will reinterpret it, such as `yes`, `null` or `1.10`.
Assuming key order is preserved and meaningful, when neither format guarantees it.
Producing very long lines that YAML folds, which changes the string unless the block style is chosen carefully.
Overlooking that JSON is valid YAML already, so the conversion is about readability rather than compatibility.
Expecting comments to appear. There are none in the source, so nothing is there to carry over.