YAML to JSON Converter

A practical guide to converting YAML into JSON: how the type rules work, what gets resolved or dropped along the way, how multi-document files and anchors behave, and the syntax errors that stop a YAML file from parsing at all.

Why convert YAML to JSON

The conversion usually runs in this direction for one of three reasons. First, an API wants JSON: you maintain a config or spec as YAML because it is pleasant to edit, but the endpoint, the database seed script or the curl call needs a JSON body. Second, debugging: when a YAML file misbehaves, looking at the parsed JSON shows you what the parser actually understood, which is regularly not what the author meant. Third, tooling: jq and most query-and-transform utilities speak JSON, so converting once buys you their whole ecosystem.

There is also a quiet fourth reason. JSON has no implicit typing, no anchors and no eight ways to write a boolean, so converting to JSON and back is a way of flattening YAML cleverness out of a file before it causes an incident.

How to use this converter

Paste YAML on the left or drop a .yaml or .yml file onto the pane; the JSON output updates while you type. A parse error shows up inline in the output pane with the line it happened on, and the page keeps working.

1. Paste or drop the YAML. Single documents, multi-document files and files using anchors or merge keys all work.
2. Read the stats. Input and output size, output lines and the number of keys, useful as a completeness check.
3. Copy or download. The output saves as a .json file.

--pretty

On by default, indents the JSON with two spaces. Turn it off for compact single-line output destined for a request body, an env var or a place where bytes matter.

--sort-keys

Sorts all object keys alphabetically. Handy for diffing two configs; leave it off when the original key order documents intent.

How YAML types map to JSON

YAML types values by how they are spelled, and that is where all the surprises live. This converter parses with the YAML 1.2 core schema, which is what modern parsers use:

The version: 1.10 row deserves a second look because it is the mistake that survives conversion: the trailing zero is gone before the converter ever sees a string, since the YAML parser already read the scalar as a float. If a value must stay text, it must be quoted in the YAML source. No converter in either direction can restore information the parser never had.

What JSON cannot keep

JSON is the smaller language, so a few YAML features have nowhere to go:

• Comments. Dropped entirely. If the YAML file is the documented source of truth, keep it; generate JSON from it rather than replacing it.
• Anchors and aliases. Resolved and expanded, see below.
• Quoting styles and block scalars. A folded scalar, a literal block and a double-quoted string that spell the same text all become one identical JSON string.
• Custom tags. A value tagged !!binary or with an application-specific tag loses the tag; the underlying scalar or collection is what comes through.
• Key order is kept, uniqueness enforced. Key order survives conversion, but a mapping with duplicate keys is rejected with an error, because silently keeping one of the two values is how config bugs are born.

Multi-document files become an array

A single YAML file may hold any number of documents separated by ---, and Kubernetes turned that feature into everyday practice: a Deployment, a Service and an Ingress routinely travel in one manifest file. JSON has no equivalent concept, so this converter makes the obvious call, one JSON array with one element per document. A file with a single document converts to that document directly, no wrapper.

Most online converters stop at the first --- or error out on multi-document input, which in practice means "does not work with Kubernetes manifests". Handling them automatically is one of the reasons this tool exists.

Anchors, aliases and merge keys are resolved

Anchors are YAML's way of writing a value once and reusing it. The classic example is a database config where &defaults marks a base mapping and <<: *defaults merges it into each environment (the sample button loads exactly this file). The converter resolves all of it: each alias is replaced with the anchored value, each merge key folds the referenced mapping into its parent, and the JSON shows the complete effective config for every environment.

That expansion is usually the most useful thing about the conversion, because it answers the question "what does this environment actually get?" without mentally following references. The trade-off is size: a value used five times exists five times in the output. If two expanded environments differ where they should not, the bug is in the YAML overrides, and the JSON just made it visible.

The YAML errors you will actually hit

YAML syntax errors cluster around a handful of causes, and the parser messages are not always helpful, so here is the translation table we wish we had earlier:

• Tab characters in indentation. Forbidden by the spec. The fix is always the same: convert tabs to spaces.
• Inconsistent indentation. A key indented three spaces under a sibling indented two starts a new (unexpected) nesting level. Pick one width and stay with it.
• Missing space after the colon. port:8080 is one scalar string, not a key and a value. YAML needs port: 8080.
• Unquoted special characters. A value beginning with {, [, *, &, # or @ collides with syntax. Quote the value.
• A lone colon inside a value. time: 12:30 parses (as a string in 1.2), but url: http://x.dev: 8080 confuses the parser into seeing a nested mapping. Quote URLs.

The error pane of this tool reports the first problem with its line number. Fix it, and the next problem (if any) appears; YAML parsers stop at the first hard error, so cleanup is sequential by nature.

YAML to JSON questions