JSON to YAML Converter - Convert JSON & YAML Online

JSON and YAML: the two languages of configuration

JSON (JavaScript Object Notation, standardised as ECMA-404 and RFC 8259) and YAML (YAML Ain't Markup Language, currently at spec version 1.2.2) are two serialisations of the same underlying data model: maps, sequences, strings, numbers, booleans, and null. Because the model is shared, any JSON document can be rewritten as YAML and any plain YAML document as JSON without loss of structure - only the surface syntax changes.

The division of labour in practice is sharp. JSON is the wire format: REST and GraphQL payloads, JWT claims, package.json, log lines shipped to Elasticsearch, document databases. YAML is the configuration format: Kubernetes manifests, docker-compose.yml, GitHub Actions workflows under .github/workflows/, Ansible playbooks, Helm values.yaml, OpenAPI specs, and the front matter in Jekyll and Hugo posts. Conversion sits at the seam between the two - turning a kubectl get -o json dump back into a readable manifest, lifting an API response into a fixture file, or making a machine-generated JSON config editable by a human.

YAML's decisive advantage is comments. JSON has no comment syntax at all, which is why configuration written in it accumulates fake "_comment" keys and why variants like JSON5 and JSONC exist. YAML also offers anchors (&name) and aliases (*name) to reuse a block without repeating it, block scalars | and >for multi-line strings, and multiple documents in one file separated by ---. All of these are lost when converting to JSON.

Syntax comparison

The same data in both formats:

JSON:                          YAML:
{"name":"Alice","age":30}      name: Alice
                               age: 30

YAML eliminates the quotation marks around keys, the curly braces, and produces one item per line - significantly more readable for humans, but requiring careful attention to indentation.

Gotchas that bite in production

• Tabs are illegal. YAML indentation must use spaces. A tab anywhere in the indentation is a hard parse error, and editors that auto-insert tabs are the single most common cause.
• The Norway problem. Under YAML 1.1, the bare words no, yes, on, and off parse as booleans - so a country-code list containing NO silently becomes false. YAML 1.2 restricts booleans to true/false, but many parsers still run in 1.1 mode. Quote ambiguous scalars.
• Leading zeros. A ZIP code or version segment written as 0755 can be read as octal, and 1.2.3 is a string while 1.2 is a float.
• Duplicate keys are a schema error in YAML but merely last-wins in most JSON parsers, so a round trip can quietly drop data.
• Colons need a following space. key:value is one scalar; key: value is a mapping.

One structural asymmetry is worth remembering: YAML 1.2 is defined as a superset of JSON, so a valid JSON document is already valid YAML and can be pasted into a YAML parser as-is. The reverse only holds for the subset of YAML that avoids comments, anchors, tags, and multi-document files.

Parsing and serialising are performed by the js-yaml library executing in this browser tab. Nothing is uploaded, so a manifest containing secrets, connection strings, or internal hostnames stays on your machine.