Convert JSON to YAML

YAML (a recursive acronym for "YAML Ain't Markup Language") is a data-serialization format that uses indentation instead of brackets and braces to express structure. It is a strict superset of JSON — every JSON document is already valid YAML — but its native block syntax is written to be read and edited by people, which is why it became the default for configuration rather than data interchange.

If you run modern infrastructure you read YAML every day: Kubernetes manifests (Deployment, Service, ConfigMap), Docker Compose files, GitHub Actions and GitLab CI workflows, Ansible playbooks, and Helm values all use it. Teams reach for it because a nested mapping reads like an outline, comments are allowed (JSON has none), and diffs stay tight — changing one setting touches one line, not a cascade of commas and closing braces.

Converting JSON to YAML is common when you already have data from an API response, a database export, or a JSON config and need to drop it into one of those tools. Because YAML is a JSON superset, the conversion is lossless for structure: objects become mappings, arrays become sequences, and scalars carry across unchanged — with quoting added only where a bare value would otherwise be misread.

In YAML, an unquoted scalar gets its type inferred from how the text looks. The tokens true, false, yes, no, on, and off become booleans; null and ~ become null; 8080 and 1.0 become numbers. That inference is convenient until your data holds a string that only looks like one of those — a ZIP code of 007, a version string of 1.0, a feature flag stored as the text "false", or a country code. Emit it bare and a YAML parser hands the next tool the wrong type.

This converter guards against that. Any string whose text would parse as a number, boolean, null, or one of YAML's alternate booleans (yes, no, on, off) is wrapped in double quotes so it round-trips as a string. Strings that contain YAML-significant characters — a leading dash, a colon, a hash, brackets, or braces — are quoted too, and an empty string becomes "".

Values that were genuinely numbers or booleans in your JSON stay bare, because their JSON type is unambiguous and needs no protection. The result is YAML that means exactly what your JSON meant: "1.0" stays a string, 8080 stays a number, and nothing silently changes type the moment a parser loads the file.

YAML offers two ways to write a collection. Block style spreads it over indented lines: each mapping key sits on its own line, and each sequence item begins with a dash. Flow style packs the collection onto one line with JSON-like punctuation — [80, 443] for a sequence, {cpu: 500m} for a mapping. Both are valid, and a document can mix them freely.

This tool emits block style with two-space indentation, which is the convention Kubernetes, Compose, and CI runners expect and what most linters enforce. Nested objects indent two more spaces under their key; sequence items sit under the key, each led by a dash. The single exception is empty collections: an empty array is written as [] and an empty object as {} on the same line, because block style has no way to represent "empty".

Block style is the reason YAML is worth using over JSON for config: small line-oriented diffs, room for comments, and structure you can scan top to bottom. Flow style is handy for a short inline list but grows hard to read as nesting deepens, which is exactly where configuration files spend their time — so this converter defaults to block and stays there.

The classic YAML trap is the "Norway problem": the country code NO parses as the boolean false unless it is quoted, and ON, OFF, and YES behave the same way. This converter quotes those cases for you, but it helps to recognize them when you hand-edit the output later or reason about why a value looks quoted.

Indentation is significant and must be spaces — YAML forbids tabs for indentation, and mixing tabs with spaces is the most common reason a manifest refuses to load. Keeping the two-space steps this tool produces keeps your linter and kubectl apply happy. Remember, too, that comments (lines starting with a hash) do not exist in JSON, so a round trip through JSON and back to YAML drops any comments the original file had.

YAML also has features JSON does not: anchors and aliases for reuse, custom tags, and block scalars (the | and > styles) for multi-line text. A JSON source contains none of these, so the converter never needs to emit them. If you later hand-author them, note that our companion YAML-to-JSON tool reads only the common subset — block mappings and sequences, quoted and plain scalars, flow style, and comments — not anchors, tags, or block scalars, which is worth knowing before you rely on a round trip.