Skip to content
snip tools

YAML to JSON converter

Convert YAML to JSON. Errors are pinpointed by line, and everything stays in your browser.

Runs 100% in your browser
YAML → JSON
 

How to convert YAML to JSON

  1. Paste your YAML. Paste a config, Compose file or CI workflow into the input.
  2. Read the JSON. The equivalent JSON appears live — and shows how each value was actually parsed.
  3. Copy or download. Grab the JSON with Copy or Download.

Same data, two notations

YAML is the human-friendly format behind Docker Compose, GitHub Actions, Kubernetes and countless app configs; JSON is what most programs and APIs actually consume. Converting between them isn't a reformat — it's a re-encoding of the same underlying data. YAML is a superset of JSON: every JSON document is already valid YAML, and YAML's core types (mappings, sequences, scalars) map one-to-one onto JSON's objects, arrays and values. That's why, for ordinary configuration data, the round trip loses nothing.

What doesn't survive the trip

A few things are part of YAML's notation rather than its data, and those don't carry over. Comments are gone, because JSON has none and they were never part of the parsed value. Anchors and aliases — YAML's way of writing a value once and reusing it — are expanded inline, since JSON has no concept of a reference. And a file holding several documents separated by --- converts only its first one.

Where you finally see how YAML parsed

The YAML validator tells you a document is well-formed; this converter shows you what it actually became. That makes it the place where type-coercion surprises appear — an unquoted no resolving to false, or a version like 1.10 losing its trailing zero. If a value comes out the wrong type, quote it in the source. Use the JSON formatter to pretty-print or further inspect the result.

Frequently asked questions

Why is converting YAML to JSON essentially lossless?
Because YAML is a superset of JSON — they share the same underlying data model of maps, sequences and scalars. A YAML mapping becomes a JSON object, a sequence becomes an array, and scalars become strings, numbers, booleans or null. For ordinary config data there's nothing in YAML that JSON can't represent, so the conversion is a straight re-encoding of the same values.
What gets dropped in the conversion?
The things that are notation rather than data. Comments disappear (JSON has none, and they aren't part of the parsed value). Anchors and aliases (&name / *name) are expanded into the values they reference, since JSON can't express the reference itself. And only the first document of a multi-document file (sections split by ---) is converted.
This is where YAML's type coercion becomes visible — what should I watch for?
A validator only tells you the YAML parses; converting to JSON shows you the actual values, which is where surprises surface. An unquoted no may appear as false, 1.10 as 1.1, and 007 as 7 — YAML's scalar resolution at work. If a value lands as the wrong type in the JSON, quote it in the YAML ("no") to force a string.
What if my YAML is invalid?
You get a clear parse error with the line of the problem, so an indentation slip or a stray tab is quick to find and fix.
Is my data uploaded?
No — js-yaml runs in your browser, so a manifest containing internal hostnames or secrets is parsed locally and never sent anywhere.