Convert YAML to JSON

YAML is the format most teams reach for when a config file has to be edited by hand. Kubernetes manifests, CI pipelines, Docker Compose, Ansible playbooks, and application settings all lean on its indentation, comments, and lack of braces. JSON is the format machines prefer: it is stricter, has no comments, and is understood by virtually every language, HTTP API, and query tool. Converting between them lets you keep authoring in YAML while handing a JSON payload to whatever needs it.

Structurally, the mapping is direct. A YAML block mapping — key: value lines at the same indentation — becomes a JSON object. A YAML sequence of - item lines becomes a JSON array. Nesting is expressed by indentation in YAML and by braces and brackets in JSON, so the tree shape is preserved exactly.

The interesting work happens at the leaves. A bare scalar like 8080 has no declared type in the text, so the converter has to decide whether it is a number, a boolean, null, or a string. That coercion step is where most surprises live, and it is spelled out in the next section.

This converter targets the slice of YAML that real config files use. On the collection side it reads block mappings, block sequences, and both flow forms — inline arrays like [prod, edge] and inline objects like {cpu: 500m} — and it lets them nest inside each other. An empty value (a key: with nothing after it and no indented block) becomes null.

Type detection follows predictable rules. true and false in any case become booleans; null and ~ become null. A token made only of digits, optionally signed, becomes a number, and decimals and scientific notation are parsed too. Two guards protect identifiers: a value with a leading zero such as 007 stays a string, and a run of more than fifteen digits stays a string so it does not lose precision as a JavaScript number. Anything you wrap in single or double quotes is kept verbatim, which is how you force "8080" or "true" to stay text.

Comments are handled with quote awareness: a # that begins a comment is stripped, even mid-line, but a # inside a quoted string is left alone. Document markers --- and ... are recognized and skipped rather than treated as data, so a file that opens with --- converts cleanly.

Being honest about limits saves debugging time, so here is what the parser deliberately leaves out. Anchors and aliases (&name to define, *name to reuse) and merge keys (<<) are not resolved: the &b or *b token is read as a literal string rather than expanded, so a manifest that relies on them will convert but produce the wrong shape. Custom and explicit tags such as !!str, !!int, or an application tag like !Ref are not interpreted — the tag text ends up inside the value.

Block scalars are the other gap. The literal (|) and folded (>) styles used for multi-line strings are not assembled. A line like script: | is read as the one-character string "|", and the indented lines beneath it are parsed as if they were structure rather than text.

Because the parser does not raise an error on any of these — it falls back to reading them as plain text — the failure is silent, which is exactly why it is worth calling out. The practical rule is to paste plain, config-style YAML. If your source uses anchors, tags, or block scalars, expand or inline them first (many YAML CLIs can emit a resolved document), then convert. For everything a typical settings or pipeline file contains, the common subset is enough.

The reason to turn config into JSON is usually a tool on the other side. Scripts and one-off automations read JSON with a single JSON.parse, no YAML dependency required. HTTP APIs expect a JSON request body, so a hand-written YAML payload can be converted and pasted straight into a client. jq, JSONPath, and most query and diff tools operate on JSON, which makes converted config easy to filter, compare across environments, or assert on in tests.

Converted config also makes a clean fixture. Committing the JSON form next to the YAML gives you a stable snapshot to diff when the config changes, and a shape your test suite can load without pulling in a YAML parser.

When you want to do more than copy the result, open it in the full editor. There the converted JSON can be reformatted or minified, validated against a schema, explored as a collapsible tree or a mind map, and questioned with the AI copilot — for example to summarize a large manifest or spot a missing field. The converter answers "what is this YAML as JSON"; the editor is where you work with the answer.