JSON to YAML

What is JSON to YAML?

This tool converts JSON into YAML — the more human-readable, whitespace-driven format commonly used for config files (Docker Compose, Kubernetes manifests, CI pipelines, GitHub Actions workflows). YAML is a superset of JSON conceptually, so the conversion is lossless for any JSON value.

How it works

The tool parses your input with JSON.parse and hands the resulting JavaScript value straight to js-yaml's dump() function with { lineWidth: -1 }, which disables line-wrapping so long strings and URLs stay on one line instead of being folded. JSON.parse preserves the original key insertion order for string keys, and dump() walks the object's own enumerable keys in that same order, so key order in the output matches the input exactly. Objects become YAML mappings (indented key: value pairs), and arrays become YAML block sequences (each item on its own - -prefixed line) rather than the more compact flow-style [a, b, c], since block style is the more common, more diffable convention for hand-edited config files.

Features

• Preserves the exact key order of the source JSON
• Block-style mappings and sequences — the readable, git-diff-friendly YAML style
• No line-wrapping, so long values stay intact on one line
• Handles arbitrarily nested objects and arrays of any depth
• Runs entirely client-side — nothing you paste is uploaded

Example

Input: { "name": "DevFormats", "version": 2, "beta": null, "features": ["format", "validate"], "author": { "handle": "devformats", "verified": true } }

Output:

name: DevFormats
version: 2
beta: null
features:
  - format
  - validate
author:
  handle: devformats
  verified: true

Common errors

Invalid JSON is caught before conversion and reported with the offending line number. A common gotcha going the other direction is that plain, unquoted YAML strings like yes, no, on, off, or version-looking numbers can be parsed as booleans or numbers by some YAML parsers — this converter always emits JSON's actual boolean/string/number types explicitly, so that specific ambiguity only bites if you hand-edit the output afterward and forget to quote a string that looks like a keyword.

Best practices

Keep the 2-space indentation the converter produces — most YAML tooling and linters (yamllint, Kubernetes manifests) expect consistent 2-space indents, and mixing tabs or inconsistent widths is one of the most common sources of "bad indentation" YAML parse errors. When editing the generated YAML by hand afterward, quote any string value that could be misread as a different type (numbers, booleans, dates) to keep it unambiguous across parsers.