JSON to YAML Converter

Why convert between JSON and YAML?

JSON and YAML describe the same data model — objects, arrays, strings, numbers, booleans and null — but they were designed for different readers. JSON is a machine interchange format: unambiguous, strict, and miserable to write by hand at any size. YAML is a human authoring format: it trades JSON's braces and quotes for indentation, and adds comments so a file can explain itself. That is why the same data keeps crossing the border. A Kubernetes manifest, a GitHub Actions workflow or a Docker Compose file is YAML because people edit it; the API it talks to, the log line it produces and the test fixture it is checked against are JSON because machines exchange them. A converter is the customs post between the two worlds, and a careful one matters: a sloppy conversion that turns the string "8080" into the number 8080, or the string "yes" into a boolean, has changed your data while claiming only to have restyled it.

How to use this tool

1. Paste JSON or YAML into the box above (or press Load sample).
2. Press JSON → YAML or YAML → JSON depending on the direction — the tool does not guess, because a JSON document is technically valid YAML too, and guessing would hide that.
3. If the input is invalid, you get the parser's error with its line and column instead of a silent failure or, worse, a half-converted document.
4. Use Copy result to take the converted document with you. Key order is preserved in both directions.

What converts cleanly — and what cannot

The shared core converts perfectly in both directions: nested objects and arrays, strings, numbers, booleans and nulls. A JSON document run through JSON → YAML → JSON comes back byte-for-byte equivalent as data (whitespace aside), and this converter is careful about the classic traps: strings that merely look like numbers or booleans are quoted in the YAML output so they re-parse as strings, and non-ASCII text passes through unescaped.

The losses all live on the YAML side, because YAML is the larger language. Comments vanish in JSON — there is no syntax to hold them. Anchors and aliases (&name / *name) are expanded into repeated plain data. Tags such as !!binary and exotic scalar styles (literal block scalars keep their content but not their style) flatten to their values. And a multi-document YAML file — several documents separated by --- — has no JSON equivalent at all; this tool converts one document and reports an error if it finds more, rather than quietly converting the first and discarding the rest.

Examples

This JSON configuration:

{"server":{"host":"example.com","port":8080,"tls":true},"routes":["/","/api","/health"]}

becomes this YAML — the same data in the shape a human would maintain:

server:
  host: example.com
  port: 8080
  tls: true
routes:
  - /
  - /api
  - /health

Run the YAML back through the other direction and you recover the original structure exactly — the only things that cannot make the return trip are comments and anchors, which JSON has no words for.

Which format should you keep?

Keep both, each where it belongs: YAML for files humans author and review (configuration, CI workflows, infrastructure definitions), JSON for anything machines exchange or validate (APIs, schemas, logs, data fixtures). If you are still deciding for a new file, our guide to JSON vs YAML walks through the differences that actually bite: YAML's significant whitespace, its many string styles, and the version traps around booleans. This converter follows YAML 1.2, the current specification.