JSON to YAML

Tips for Generating Clean, Trustworthy YAML

• Don't manually add quotes before converting. The quoting logic already checks each value against YAML's actual ambiguity rules — adding your own guesswork on top usually just produces double-escaped strings.
• Turn off Multi-line Block Scalars only if a downstream tool line-diffs the file — block scalars are far more readable, but they do spread one JSON string across several YAML lines.
• Use Flow Style Arrays for short tag or flag lists, and leave it off for anything that might later gain nested objects — flow style degrades fast once real structure shows up.
• Sort Keys before diffing two versions of the same config in the Text Diff Checker — key-order noise disappears and only real changes remain.

Features

Why JSON and YAML Look Different But Mean the Same Thing

YAML is technically a superset of JSON — any valid JSON document is already valid YAML. What people actually want when they ask for a converter isn't just re-parseable output, though; it's YAML that looks like YAML. Curly braces and quotation marks replaced with indentation. Dashes instead of square brackets. The compact, readable style you'd expect in a Kubernetes manifest or a CI pipeline file, not JSON wearing a YAML costume.

Getting there means making real decisions: when is a string safe to leave unquoted, when does an array deserve to stay on one line, how should a paragraph of text be laid out. This converter makes each of those decisions deliberately, and lets you override the ones that matter for your use case instead of hard-coding a single house style.

Where the JSON Usually Comes From

Rarely hand-typed — more often it's an API response saved from a browser, an export from a database or admin panel, or the output of another converter, like CSV to JSON or XML to JSON, feeding into this one as a second step on the way to a YAML-based config.

The Quoting Decisions That Make or Break Generated YAML

Unquoted YAML strings are readable, but they're also where naive converters quietly corrupt data. A version string like "2.0" written unquoted becomes the number 2 in some parsers. A status field containing "yes" or a country code "NO" becomes the boolean true or false under YAML 1.1, which is still what Docker Compose and a lot of production tooling actually parses with — this is widely known as the Norway problem, named for exactly that country-code case. This converter checks every string against the full reserved-word list, numeric patterns, and structural characters before deciding to leave it unquoted, so values that look dangerous get quoted automatically rather than becoming a debugging session three deploys later.

Multi-Line Strings: Block Scalars vs Escaped Newlines

A JSON string with embedded line breaks has two honest YAML representations. The lazy one wraps it in quotes and escapes every newline as literal \n characters — technically correct, completely unreadable the moment the text is more than a sentence. The right one uses a block scalar: a | marker followed by the text laid out across real, indented lines, exactly as a person would write it in an editor. This converter defaults to block scalars for any string containing a line break, because that's what actually makes generated YAML readable instead of just technically valid.

Flow vs Block Style for Arrays

Block style — one item per line, each prefixed with a dash — is the YAML convention most people expect and the safest default for arrays that might grow more structure later. Flow style — [dev, tools, free] on a single line — is JSON-like and genuinely useful for short, simple lists like tags or feature flags where one-item-per-line is just extra vertical space. This converter automatically restricts flow style to arrays that contain only plain values; the moment an array holds a nested object, it falls back to block style regardless of the setting, because flow-style nesting is where YAML readability actually breaks down.

Why There's No Tab Option Here

Every other formatter on this site — JSON, XML, CSV — offers a Tab indent choice alongside spaces, because none of those formats care what whitespace character sits between a value and its parent. YAML is the exception: the specification explicitly forbids tab characters for indentation, and most parsers reject a tab-indented file outright rather than quietly accepting it. That's why this converter only offers 2 or 4 spaces — not a missing feature, but a rule inherited directly from the format itself.

Numbers, booleans and null pass straight through unchanged during conversion, with none of the quoting logic applied to strings — a JSON 42 becomes a YAML 42, true stays true, and null becomes YAML's own null, since none of those types carry the ambiguity that makes string quoting necessary in the first place.

Who Actually Converts JSON to YAML

DevOps engineers turning an API response or exported config into a Kubernetes manifest or Docker Compose file. Backend developers writing CI/CD pipeline definitions — GitHub Actions, GitLab CI, CircleCI — who have the data in JSON but need it in the YAML the platform actually reads. Anyone documenting a JSON API who wants to show the same data in YAML because it reads more naturally in a config-file context.

From Kubernetes Manifests to CI Pipelines: Real Scenarios

Bootstrapping a Kubernetes ConfigMap. Export application settings as JSON from an admin panel, convert to YAML, and paste directly into a manifest — with Sort Keys on, the result is easy to scan and easy to diff on the next update.

Writing a GitHub Actions workflow from a JSON template. Convert a JSON-based pipeline definition to YAML, and the multi-line block scalar handling keeps any embedded shell scripts or multi-line commands readable instead of collapsing them into an escaped mess.

Migrating an app config from JSON to YAML. Convert once, review the output, and commit — no manual reformatting, and no risk of a stray "yes" or "no" silently becoming a boolean along the way.

Everything Runs in Your Browser

Config files carrying database credentials, internal service names, and infrastructure details are exactly the kind of data that shouldn't pass through a third-party server. Parsing and conversion both run as plain JavaScript in your browser tab — nothing you paste or upload is transmitted anywhere, and the tool keeps working offline once the page has loaded.

When to Keep the Data as JSON Instead

If the destination is a REST API, a JavaScript application, or anything that already speaks JSON natively, converting to YAML and back is pure overhead — leave it as JSON. This tool also targets the common 90% of real-world documents; it doesn't implement YAML features JSON has no equivalent for, like anchors, aliases, or custom tags, since there's nothing in a JSON source to generate them from. For those, a YAML file written and maintained directly is the right tool, not a converter — and for reading such a file back into JSON, see YAML to JSON.

Frequently Asked Questions