GitGudgit gud
gitgudRun an audit
‹ all tools
Convertgitgud / tools

YAML ⇄ JSON Converter

Convert YAML to JSON and back, with the line and column of any parse error.

Runs entirely in your browser — nothing you paste is uploaded.

About YAML ⇄ JSON Converter

YAML is what configuration is written in and JSON is what programs read, so this conversion happens constantly — checking what a Kubernetes manifest actually parses to, turning an OpenAPI spec into something a script can walk, or pasting a JSON payload into a CI config that wants YAML.

Both directions are supported, along with multi-document streams: YAML separates documents with `---`, and a stream of them converts to a JSON array. Parse errors report the line and column from the parser's own source mark, which is the difference between finding a bad indent in ten seconds and reading the whole file.

The parser loads with a safe schema. YAML's specification allows tags that construct arbitrary objects, and historically the most common way to get remote code execution out of a config file was to hand an untrusted YAML document to a full-schema loader. Code-bearing tags here are rejected with an error rather than resolved.

Worth knowing about the format itself: YAML's implicit typing is where most surprises come from. Unquoted `yes`, `no`, `on` and `off` are booleans in YAML 1.1, `1.0` is a float, `08` is an error in some parsers because it looks like invalid octal, and a bare country code like `NO` becomes `false`. Quote anything you mean as a string.

Frequently asked

Why did my YAML string become a boolean?

YAML 1.1's implicit typing treats `yes`, `no`, `on`, `off`, `true` and `false` as booleans when unquoted. The classic case is a country list where Norway's `NO` becomes `false`. Quote the value — `"NO"` — and it stays a string.

Is YAML a superset of JSON?

YAML 1.2 is, in practice: any valid JSON document is valid YAML. The reverse is not true — YAML has anchors, comments, multiple documents and unquoted strings that have no JSON equivalent, which is why converting YAML to JSON can lose information.

What happens to anchors and aliases?

They're resolved during parsing, so the JSON output has the referenced content expanded inline. Converting back to YAML produces the expanded form, not the original anchors — the structure survives, the abbreviation doesn't.

Can a YAML file execute code when parsed?

Only if the parser is loaded with a schema that permits code-bearing tags, which this one is not. That configuration has produced real remote-code-execution vulnerabilities in several languages. Never load untrusted YAML with a full schema.

Tabs or spaces for indentation?

Spaces, always. YAML forbids tabs as indentation outright, and a tab that sneaks in from an editor produces a parse error whose message rarely mentions tabs.

Related tools