YAML to JSON Converter

YAML is written for people and JSON is read by programs, so the same data often has to cross between them: a Kubernetes or docker-compose snippet going into a script, a CI config becoming a test fixture, or front matter from a Markdown file feeding an API request. This converter reads the YAML and writes the equivalent JSON, keeping the nesting and the lists exactly as the indentation describes them.

It is also a quick way to see how YAML will actually be read. JSON has no ambiguity about types, so the output shows at a glance whether 3.10 became the number 3.1, whether a value is a string or a boolean, and which key a nested value belongs to.

Everything runs in your browser: the YAML you paste, open or drop is parsed on your device and nothing is uploaded. That makes it reasonable for configuration that names internal hosts, ports or environments.

It reads block YAML the way config files are written. Indentation defines nesting, lines starting with - are list items (including lists of mappings, where the keys of one item line up under each other), and a key followed by nothing takes the indented block below it as its value. Comments after # are ignored, quoted strings keep their exact content, and one-line collections such as [a, b] or {x: 1} are understood.

Multi-line text works in both YAML styles: | keeps the line breaks and > folds lines into spaces, with the usual - and + endings to strip or keep trailing newlines. A --- at the top is accepted; a second document in the same file is not.

Values are typed by the YAML 1.2 core rules. true, false, null, ~, integers, decimals and 0x or 0o numbers are converted; everything else is text. Two deliberate protections: numbers with leading zeros (ZIP codes, IDs like 007) stay text, and integers too large to hold exactly in JSON stay text, so no value silently changes.

If the YAML is malformed, you get an error naming the line instead of JSON that looks complete but is not. The common ones: a tab used for indentation (YAML only allows spaces), a key that appears twice in the same mapping, a line indented deeper than its neighbours, and a quote that is never closed.

Some YAML features are refused on purpose: anchors and aliases (& and *), tags (!), merge keys (<<), complex keys (?) and files with more than one document. Converting those correctly needs the full YAML specification, and quietly getting them wrong would be worse than saying so.

One behaviour to know: yes, no, on and off are text here, as YAML 1.2 defines them. Older YAML 1.1 tools read them as booleans. If the program that will read your file expects booleans, write true and false.

Compare the structure with what you expected: every top-level key present, lists where the YAML had dashes, and nested objects under the right parents. Because the parser follows indentation strictly, a value that appears under the wrong parent almost always means the YAML itself was indented inconsistently.

Spot-check types where they matter. Version numbers such as 1.10 become 1.1 unless they are quoted in the YAML, so quote any value that must stay text. Leading-zero values are already safe.

For anything official, financial or contractual, compare the JSON with the source before relying on it. The conversion is mechanical and exact, but it can only reflect what the YAML actually says.