JSON ↔ YAML Converter

How to use it

1. Pick a direction: JSON → YAML or YAML → JSON.
2. Paste your document. Conversion runs as you type.
3. Copy or download the result.

The Norway problem, and why quoting matters

The most valuable thing this converter does is not the conversion — it is deciding what to quote.

YAML 1.1 treats a generous set of bare words as booleans: yes, no, y, n, on, off, true, false, in several capitalisations. That rule produces a famous bug. A list of country codes written as

countries:
  - GB
  - NL
  - NO

loads as ["GB", "NL", false]. The Norwegian entry became a boolean. The same trap catches version numbers (1.0 is a float, 1.0.0 is a string), times (22:30 may parse as a sexagesimal number under YAML 1.1), and leading-zero values such as 08 — invalid as octal in some parsers, a plain string in others.

This tool quotes any scalar that a parser might reinterpret, so the round trip is lossless. It is slightly noisier to read, and deliberately so: correctness first.

What each format is actually good at

JSON is a data interchange format. It is unambiguous, machine-generated, machine-consumed, and its grammar fits on a page. Nobody enjoys writing it by hand — no comments, no trailing commas, everything double-quoted — and that is fine, because it was never meant to be hand-written.

YAML is a configuration format. Comments, no closing brackets, multi-line strings, and far less punctuation make it comfortable for humans. The price is a large and surprising specification, whitespace that carries meaning, and type inference that occasionally guesses wrong. Kubernetes manifests, CI pipelines, Docker Compose and Ansible playbooks all live here.

A reasonable rule: if a human writes it, YAML; if a program writes it, JSON.

Round-trip limits

Four YAML features have no JSON counterpart, so they cannot survive a conversion:

• Anchors and aliases — &defaults / *defaults let one node be reused. JSON has no references, so a converter must either expand them (duplicating data) or fail. This tool does not support them.
• Multi-document streams — several documents separated by --- in one file. JSON has exactly one root value.
• Complex keys — YAML allows a mapping or sequence as a key. JSON keys are always strings.
• Custom tags — !!python/object and friends are parser-specific and, in several languages, a remote-code-execution hazard when loading untrusted YAML.

Comments are the fifth casualty, and the one people notice most. Converting a commented config to JSON and back returns working YAML with all the explanation stripped out.