How to Convert JSON to YAML for Configs, CI Pipelines and Kubernetes Manifests

JSON is great for machines, YAML is great for humans

If you have ever hand-edited a Kubernetes manifest, a GitHub Actions workflow, or a docker-compose file, you already know why YAML exists. JSON is unambiguous and easy for programs to emit, but its braces, brackets and mandatory quotes make it noisy to read and error-prone to edit by hand. YAML keeps the same data model — maps, lists and scalars — and strips the punctuation, using indentation to show structure instead. The snag is that most tools, APIs and databases hand you JSON, so you constantly need to translate one into the other.

How the conversion works

JSON and YAML describe the same three building blocks, so the mapping is almost one to one:

• A JSON object becomes a YAML mapping — key: value pairs, one per line.
• A JSON array becomes a YAML sequence — a list of - item lines.
• Strings, numbers, booleans and null carry across unchanged, except YAML usually drops the quotes.

The catch is indentation. YAML uses two spaces per level by convention and forbids tabs entirely, so every nested level must be spaced consistently. The JSON to YAML tool handles that for you: it parses your JSON with the browser's own JSON.parse, then serializes it as YAML with a fixed two-space indent and no line wrapping, so long strings stay on a single line. Because it validates the JSON as it parses, an unbalanced brace or trailing comma is caught immediately and reported under the input, so you never generate YAML from broken data.

A worked example

Paste this JSON:

{
  "name": "filemarkr",
  "replicas": 3,
  "tags": ["json", "yaml"],
  "config": { "indent": 2, "note": "runs in your browser" }
}

and you get back clean, commit-ready YAML:

name: filemarkr
replicas: 3
tags:
  - json
  - yaml
config:
  indent: 2
  note: runs in your browser

Notice how the nested config object indents one level deeper and the array expands into dash-prefixed items — exactly the shape a CI runner or Helm chart expects.

Common pitfalls to watch for

• The "Norway problem." Different YAML parsers disagree about bare words like yes, no, on and off. A value that stays a string in one parser can become a boolean in another (famously, the country code NO). If a string could be misread downstream, keep it quoted.
• Numbers that are really strings. A zip code like "01234" is a string in JSON, but once the quotes drop it may be read as the number 1234. Preserve leading zeros by quoting.
• Tabs. If you later edit the YAML by hand, never use tabs for indentation — YAML rejects them outright.
• Comments are one-way. JSON has no comments, so a round trip through JSON strips any # comment lines from the original YAML.

Round-tripping back

The conversion is lossless for data (not comments), so you can go the other direction any time with the YAML to JSON tool — handy when a config file must be fed to an API that only speaks JSON. If your source JSON is messy to begin with, run it through the JSON Formatter first so structural mistakes are easy to spot before converting.

Conclusion

Converting JSON to YAML is mostly mechanical, but the details — indentation, implicit typing and quoting — are where hand-written configs break. Let the browser do the transform deterministically, keep an eye on the quoting rules above, and you will get manifests that are both readable and correct. Everything runs locally in your browser, so you can paste production config without it ever leaving your machine.