How to use YAML ⇄ JSON Converter
What it does & when you need it
You have a Kubernetes manifest, a GitHub Actions workflow, or a docker-compose
file in YAML, and you need it as JSON to feed an API, a schema validator, or a
piece of tooling that only speaks JSON — or the reverse, because a hand-written
JSON config is painful to read and you want the terser YAML form. This converter
runs both directions in your browser: it parses YAML into a data model and
serializes it as JSON, or parses JSON and emits YAML. Nothing is uploaded, which
matters when your config holds secrets, connection strings, or internal
hostnames. When a document won't parse, you get the error message instead of a
blank output, so you can see what broke.
How to use
- Pick a direction with the toggle: YAML → JSON or JSON → YAML.
- Paste your document into the input buffer, press Sample to load an example
config, or Upload a
.yaml,.yml, or.jsonfile. - The output updates as you type. Press Copy result (or
Ctrl/Cmd+Enter) to grab it. If the input is malformed, the output panel shows the parser error rather than a partial result.
Things worth knowing
JSON is (almost) a subset of YAML. As of the YAML 1.2 spec, valid JSON is also valid YAML, so pasting JSON into the YAML → JSON side usually just round-trips cleanly. The reverse is not true: YAML has multi-document streams, comments, anchors, and block scalars that have no place in the JSON grammar, so plenty of YAML cannot survive a trip through JSON unchanged. Treat JSON as the smaller, stricter target format. If you want to tidy the JSON that comes out, send it to the JSON Formatter.
Indentation is load-bearing, and tabs are illegal. YAML uses indentation to express structure the way Python does, and the spec forbids tab characters for indentation entirely — you must use spaces. A single stray tab, often pasted in from an editor that "helpfully" converts spaces, is the most common reason a YAML document refuses to parse. If you get an indentation error and the file looks right, search it for a literal tab.
Beware the Norway problem. Under YAML 1.1-style boolean rules, the bare words
no, yes, on, and off (in several casings) are parsed as booleans. That
means a country-code list containing NO for Norway can silently become false,
and a version: on field becomes true. The fix is to quote any scalar that
could be mistaken for a boolean, number, or null — "NO", "on", "1.20" —
which forces it to stay a string. When you convert to JSON and see false where
you expected a code, this is almost always why.
Converting to JSON is lossy by design. YAML comments introduced with #
carry no data, so they disappear the moment you serialize to JSON — JSON has no
comment syntax at all. Likewise, anchors and aliases (&name to define, *name
to reference) are a YAML feature for reusing a node; converting to JSON expands
every alias into a full copy of the referenced value and discards the anchor
mechanism. Don't rely on a JSON round-trip to preserve either. Once your data is
structured, you might generate matching TypeScript interfaces
from the JSON output.