Nifty Tools

JSON to YAML

Convert json to yaml in your browser. Paste JSON and copy or download YAML 1.2 with reserved-word quoting handled. No upload, no signup, no watermark.

Processing mode: Local Browser-local

Waiting for JSON.

How to use it

JSON to YAML Converter — Free, In Your Browser

  1. Paste JSON into the editor. Up to ~10 MB of pasted text per run.
  2. Click Convert and the emitter walks the parsed value, indenting nested objects and arrays with two spaces per level.
  3. Copy the YAML to the clipboard or download it as a `.yaml` file. Nothing leaves your browser.

Good for

Common use cases

People convert JSON to YAML when the next system on the path expects YAML and accepts nothing else. Kubernetes manifests, GitHub Actions workflows, GitLab CI pipelines, CircleCI configs, Docker Compose files, Helm charts, Ansible playbooks, OpenAPI specifications, Hugo and Jekyll front-matter, and most modern infrastructure-as-code tools all standardise on YAML for the human-readable surface. Many of these systems publish their reference examples in JSON for compactness or because the underlying API speaks JSON, leaving the operator to translate the snippet by hand. The translation is mechanical but error-prone — a missed indent or an unquoted `no` that legacy YAML parsers (Ruby Psych, PyYAML default mode, several Go libraries) read as `false` is a pull request blocked by a CI failure. Doing the conversion in the browser (no upload, no signup, no watermark) produces a YAML 1.2 emission with reserved-word quoting, number-look-alike quoting, and 2-space indents already handled, so the output is paste-ready in any of the tools above. Browser-local conversion also keeps internal API responses, secrets-template scaffolding, and unreleased configuration off third-party servers.

Processing mode

Browser-local

Files are processed by your browser. They never reach our servers.

Questions

JSON to YAML Converter — Free, In Your Browser FAQ

Why does the converter quote strings like "no", "off", or "1.20"?

Strict YAML 1.2 reserves only `true`, `false`, `null`, and `~` as boolean/null literals, but `yes`, `no`, `on`, and `off` remain a real-world coercion trap: most popular parsers (Ruby Psych, PyYAML in default mode, several Go libraries) still default to YAML 1.1 semantics where those words decode to booleans. The same trap exists for strings that look like numbers (Kubernetes API version `"1.20"` becomes the float `1.2` if left unquoted, dropping the trailing zero) and for ISO date strings (`"2026-04-26"` decodes to a Date object on YAML 1.1 parsers). The emitter quotes all of those forms so the YAML reads back to identical JSON regardless of which parser you hand it to. This is exactly the conservative-quoting behaviour a strict YAML validator expects.

Does the converter use block style or flow style?

Block style throughout — nested objects use indented `key: value` pairs, nested arrays use `- ` prefixes, and only empty containers fall back to the inline `{}` and `[]` forms. This matches the convention every Kubernetes manifest, GitHub Actions workflow, and Docker Compose file already uses, so the output is paste-ready into those configs without restyling. Flow-style emission for compact one-liners is intentionally not offered — mixing the two styles in the same file is a known source of YAML parser confusion.

What happens to multi-line strings, special characters, and Unicode?

Multi-line strings are double-quoted with `\n` escapes, so a JSON value containing line breaks survives the conversion as a single YAML scalar. Strings containing YAML indicator characters (`:`, `#`, `&`, `*`, `!`, `|`, `>`, `'`, `"`, `%`, `@`, `` ` ``, `,`, `[`, `]`, `{`, `}`) are double-quoted so they don't change the parser's interpretation. Unicode characters pass through untouched — the emitter does not escape them, so emoji, accented characters, and CJK text all render natively in the output YAML.

Is the YAML output guaranteed to round-trip back to the same JSON?

For every JSON value the converter accepts, yes — the emission strategy is built around that contract. Reserved words, number-look-alikes, ISO date/timestamp strings, and YAML indicator characters are all quoted; arrays and objects keep their first-seen key order; and `Infinity`, `-Infinity`, and `NaN` (which JSON does not actually permit) are emitted as `null` because YAML's special floats are not portable across parsers. If round-trip fidelity matters for your pipeline, run the YAML back through a `js-yaml` or PyYAML parser and compare — the result should be deep-equal to the source.

Is there a file size limit for the JSON paste?

Each paste stays under roughly 10 MB. The parser builds the full nested value in memory before emitting, so very large configs can stall on lower-RAM devices. For everyday Kubernetes manifests, OpenAPI specs, and CI configs this limit is comfortable. For multi-megabyte data dumps the YAML output isn't usually the right deliverable — that's CSV-or-Parquet territory rather than human-readable config territory.

Will this tool stay free?

The basic workflow is designed to stay free. Paid upgrades later will focus on bigger limits, batch work, OCR, saved presets, and ad-free use.