YAML to JSON converter — convert YAML to JSON online

yes and no are strings here, not booleans

This is the single most common YAML surprise, and it is worth being precise about. YAML 1.1 treated yes, no, on and off as booleans. YAML 1.2 removed that: only true and false are booleans, in any of the casings true, True or TRUE.

This converter follows YAML 1.2, so enabled: no becomes "enabled": "no" — a string. If the tool that consumes your file follows YAML 1.1, it will read the same line as false. That disagreement is real and it is why the advice is always to quote the value, or write false outright.

The related trap has a name — the Norway problem, where a country list containing NO lost Norway to a boolean. Under 1.2 it does not happen: NO stays the string "NO".

Numbers, and the leading zero that disappears

An unquoted 007 is the number 7, and the padding is gone. 0x1F is 31, and 3.10 is 3.1. This is correct YAML and it is also how a zero-padded account code or a version string quietly changes meaning. The fix is in the source document, not here: quote it, and it stays a string.

Dates are safer than you might expect. 2026-08-17 stays the string "2026-08-17", because the YAML 1.2 core schema has no timestamp type — so it survives the trip unchanged rather than becoming a formatted date.

Anchors, aliases and merge keys

YAML can define a value once with an anchor (&base) and reuse it with an alias (*base). JSON has no such reference, so each alias is expanded into a full copy. Expect the JSON to be larger than the YAML, and expect the sharing to be gone — editing one copy afterwards no longer changes the others.

Merge keys (<<: *base) are resolved properly rather than left as a literal key called <<. That is a deliberate choice: strictly, the merge key is a YAML 1.1 feature that 1.2 did not carry over, but docker-compose files, GitLab CI pipelines and Helm values lean on it constantly, and a converter that produced a "<<" key would be technically defensible and useless.

Files holding more than one document

A --- separator starts a new document, and a single Kubernetes manifest routinely holds five. JSON has no multi-document form, so a file with more than one document converts to a JSON array, one item per document, in order. A note appears above the output saying how many were found — silently converting only the first, which is what a naive parser does, would throw away most of your file.

What this refuses, and why

Two things are rejected rather than approximated. !!binary has no JSON equivalent, and the plausible workarounds either produce an object of numbered bytes or silently invent a base64 string that was not in your data. Duplicate keys are an error too — JSON would keep the last one and drop the rest, and a config file with the same key twice is a bug you want to know about.

One thing is converted but flagged: .inf and .nan become null, because JSON has no way to write either. A note appears when that happens.

Going the other way

The JSON to YAML converter is the reverse. Once you have JSON, the JSON diff can compare two documents as data rather than as text, which is the practical way to see what actually changed between two versions of a manifest.

Nothing is uploaded

Parsing happens in your own browser. YAML files are configuration, and configuration is where secrets live — registry credentials, connection strings, API keys in a values file somebody meant to template. None of it is transmitted, stored or logged here.