JSON to YAML Converter

Turning JSON into a readable YAML config

YAML earns its place in config files by being easy to read and edit: no braces, no quotes on ordinary strings, indentation instead of punctuation, and comments allowed. Kubernetes manifests, GitHub Actions workflows, Docker Compose files and countless tool configs all use it. Converting a JSON payload, API response or exported settings blob into YAML is often the first step in turning it into something a human maintains.

Because every JSON value is also a valid YAML value, the conversion is lossless — the data that comes out is exactly the data that went in, just written in block style with your chosen indentation. A top-level object becomes a mapping, a top-level array becomes a sequence of "- " items, and a bare value is emitted as-is.

Quoting is applied conservatively. A string is left bare unless doing so would change its type: "123", "true", "null", "3.14" and date-like strings get quotes so YAML does not silently reinterpret them as a number, boolean, null or timestamp. Everything else stays unquoted, which is what makes the output pleasant to read.

The "sort keys" option alphabetises every object's keys, which is handy for producing a stable file that diffs cleanly when the source key order is arbitrary. Repeated objects are written out in full rather than collapsed into anchors and aliases — more verbose, but easier to follow and safer to hand-edit.

The JSON is parsed and the YAML generated locally with js-yaml. Nothing is uploaded.

Worked example

JSON in:
{"service":"api","replicas":3,"debug":false,"env":{"LOG_LEVEL":"info","PORT":"8080"},"tags":["web","v2"]}

YAML out:
service: api
replicas: 3
debug: false
env:
  LOG_LEVEL: info
  PORT: '8080'
tags:
  - web
  - v2

PORT stays quoted because it was a string in the JSON; written bare, YAML would read 8080 as a number. Strings such as 'yes', 'no', 'on', 'off', 'null', '0x1F' and '2024-01-01' are quoted for the same reason — older YAML 1.1 parsers, still used by some tools, would otherwise turn yes and no into booleans.

Before you paste the YAML into a config file

• Add comments afterwards. JSON has none, and comments are one of the main reasons to use YAML for configuration.
• Check the indentation your tool expects. Kubernetes, Docker Compose and GitHub Actions all accept 2 spaces; never use tabs in YAML.
• Keep secrets out: API keys and passwords in a JSON export should become references to a secret store, not values in a committed YAML file.
• Very long strings are folded onto several lines once they pass 100 characters; the data is unchanged.

YAML features worth adding by hand

• Comments with # — explain why a value is set, not just what it is.
• Multi-line strings: | keeps line breaks exactly (scripts, certificates), > folds lines into one paragraph (long descriptions).
• Anchors and aliases (&defaults and <<: *defaults) to share repeated blocks — the converter writes repeats out in full, so introduce these yourself if the file has a lot of duplication.
• Consistent quoting for values that must stay strings, such as version numbers like "1.10", which a YAML parser would otherwise read as the number 1.1.

If the YAML will be read by an older YAML 1.1 parser — PyYAML is a common one — values such as yes, no, on and off are booleans there, which is why this converter quotes them.