Skip to main content

JSON to YAML Converter

Convert JSON to YAML format instantly.

Reviewed by · Last reviewed

How to Use the JSON to YAML Converter

  1. Paste JSON into the input pane. A full document, an API response copied from DevTools, or a JSON object body from Postman all work. The converter validates as you click Convert.
  2. Click Convert to YAML. Objects become block mappings, arrays become block sequences with - markers, and primitives keep their types.
  3. Review the YAML in the output pane. If the input is invalid JSON the red error banner reports the character offset of the problem.
  4. Copy the result into your Kubernetes manifest, Docker Compose file, or Ansible playbook. The output uses two-space indentation, which is the de facto standard across the ecosystem.

Inside the Converter

The first step is JSON.parse, which hands back a JavaScript value tree. That gives the converter a strict input contract: duplicate keys are already collapsed (the last one wins in every modern JSON parser), numeric strings stay strings, and the only value types possible are objects, arrays, strings, numbers, booleans, and null. The converter then walks that tree recursively and emits YAML block syntax with indentation proportional to depth.

Strings are quoted only when necessary: values that would be ambiguous with YAML reserved tokens (true, false, null, yes, no), values that parse as numbers, values that start with special characters (-, :, ?, !, &, *, [, {), or values containing newlines or embedded quotes. That matches the YAML 1.2 rules for plain scalars described at yaml.org/spec. Empty arrays emit [] and empty objects emit {} using flow style because block style has no way to show an empty collection.

Scenarios Where This Is Handy

  • Migrating a JSON configuration file to YAML for a tool like Serverless Framework or Helm that expects YAML.
  • Converting API responses into YAML for inclusion in documentation where the readability of YAML beats JSON brace soup.
  • Preparing test fixtures for Go, Python, or Ruby tests that use YAML loaders.
  • Taking a Postman saved request body and turning it into a YAML snippet for a README.
  • Building a Kubernetes ConfigMap whose data originated as JSON from an upstream service.
  • Producing a readable diff of a large JSON config by converting both versions to YAML and diffing the YAML files.

Edge Cases

  • Numeric strings. A JSON value of "123" (string) becomes YAML '123' so it is not later re-parsed as a number. Without the quotes, a YAML parser would round-trip it back as an integer.
  • Special float values. JSON does not have NaN or Infinity - those are invalid JSON. If your source is JavaScript-style output with them, strip them first.
  • Key characters. Keys containing colons, spaces, or special markers are quoted. YAML permits almost any string as a key but a bare word is easier to read, so the converter only quotes when necessary.
  • Duplicate-looking keys. JSON permits duplicate keys syntactically, but parsers collapse them. By the time the converter sees the data there is only one of each key, so duplicates from the original source are already lost.
  • Deeply nested structures. Indentation by two spaces means 20-level-deep JSON produces 40 leading spaces per line. That is legal YAML but hard to read; consider restructuring the source if the depth is that extreme.

Why JSON and YAML Coexist

JSON was specified in RFC 8259 (and in parallel as ECMA-404). It optimises for machine parsing: a small strict grammar, no comments, no multi-line strings, no references. YAML, specified at yaml.org, optimises for human readability: indentation-driven structure, comments, anchors, and explicit type tags. A correctness consequence worth knowing: every JSON document is valid YAML 1.2 (YAML is a strict superset), but the converse is not true - most real YAML has features JSON cannot express. That asymmetry is why YAML tends to dominate configuration files (hand-edited, commented) while JSON dominates wire formats (machine-generated, machine-consumed). Kubernetes accepts both for the same API, and internally normalises to JSON before processing.

Alternative Converters

The Go-based yq tool (from mikefarah/yq) is the community favourite for scripted conversion. yq -P '.' file.json produces pretty YAML that matches the Kubernetes style guide. Python users have ruamel.yaml, which preserves ordering and comments if you ever round-trip back. Editor plugins (VS Code Redhat YAML, IntelliJ YAML) offer visual JSON-to-YAML conversion with validation against schemas. This in-browser tool is fastest for one-off conversions and avoids the security friction of pasting proprietary JSON into a cloud service, but for repeatable pipeline use the CLI tools above.

Frequently Asked Questions

Which indentation does the output use?

The converter emits two-space indentation by default, which is the convention used in the Kubernetes, Helm, Ansible, and Docker Compose ecosystems. Four-space indentation is technically valid YAML but looks misaligned in those projects because their tooling and examples all assume two. If you need a different width, post-process with a YAML reformatter like <code>yq</code>.

How are JSON booleans and null represented?

A JSON boolean <code>true</code> becomes the YAML literal <code>true</code>, the JSON <code>false</code> becomes <code>false</code>, and <code>null</code> becomes <code>null</code>. The converter does not use alternative spellings like <code>yes</code>/<code>no</code> or the tilde <code>~</code> for null, because those are YAML 1.1 conventions that modern strict parsers in YAML 1.2 mode may reject or treat as strings.

Does it preserve the order of object keys?

Yes. JavaScript objects iterate keys in insertion order for string keys per the ECMAScript specification (since ES2015), and the converter walks them in that order when emitting YAML. So if your JSON has <code>apiVersion</code> before <code>kind</code> before <code>metadata</code>, the YAML does too. That matters because Kubernetes CRDs conventionally list these top keys in a specific order.

What happens with very large JSON documents?

The converter uses <code>JSON.parse</code> followed by a recursive walk, so it scales linearly with document size. In practice anything under ten megabytes converts in well under a second on a modern laptop. Larger inputs may briefly freeze the tab during parsing. For very large payloads prefer the command-line <code>yq</code>, which streams and uses more memory-efficient serialisation.

Is my JSON uploaded to any external service?

No. The page ships a Preact island that runs the converter locally; there is no fetch to a backend and no persistent storage of your input. You can verify with the DevTools Network panel - clicking Convert triggers zero new requests. Because JSON configs routinely contain credentials, database passwords, or personal data, the local-only guarantee matters.

Can I convert a JSON array of top-level items?

Yes. A top-level JSON array emits a YAML block sequence at the root of the document. Each element is indented with <code>- </code> as its marker. This is slightly uncommon because most YAML configs have an object at the root, but it is fully valid per the YAML spec and some tools (Ansible variable files) expect this shape.

How are nested arrays inside objects handled?

Arrays inside object values use block-sequence syntax with each item on its own line. Nested arrays (arrays of arrays) produce deeper indentation levels, and arrays of objects emit the first key of each object on the same line as the dash. This matches the output conventions of <code>yq</code> and go-yaml and should look familiar to anyone who writes Ansible.

What about JSON comments?

JSON per RFC 8259 has no comment syntax; any <code>//</code> or <code>/* */</code> in your source means your input is not actually JSON but JSON5, HJSON, or JSONC. <code>JSON.parse</code> rejects all of these. Strip comments before pasting, or parse with <code>json5</code> first in a Node script. The YAML output will not have any comments either, because there is nowhere for them to come from.

Why are some strings quoted and others not?

YAML has a rule that plain (unquoted) scalars cannot look like numbers, booleans, null, or start with reserved characters. The converter quotes exactly those cases and leaves plain strings unquoted for readability. For example <code>"version": "1.0"</code> becomes <code>version: &#39;1.0&#39;</code> because without the quotes YAML would parse it as the number 1.0 and lose the string type.

Does the output work in Kubernetes manifests?

Yes. The generated YAML parses cleanly with <code>kubectl apply</code>, which uses the <code>sigs.k8s.io/yaml</code> parser. That parser is strictly YAML 1.2 and converts internally to JSON before validating against the API schema, so any round-trip-safe YAML (which this converter produces) works. Just remember to include the three <code>apiVersion</code>, <code>kind</code>, and <code>metadata</code> keys at the top level that Kubernetes requires.

More Developer Tools

Base64 Encoder & Decoder

Encode UTF-8 text to Base64 online or decode Base64 back to UTF-8 and plain text. Runs in your browser with no upload.

Open tool

Bulk URL Encode / Decode

Encode or decode many URLs at once. Paste a newline-separated list and the tool processes each line in parallel, preserving order and blank lines.

Open tool

Code Screenshot

Create beautiful code snippet images with customizable themes.

Open tool

Color Converter

Convert colors between HEX, RGB, HSL and CMYK formats.

Open tool

Cron Expression Parser

Parse cron expressions into human-readable schedules with next run times.

Open tool

CSS Formatter / Minifier

Format, beautify and minify CSS code.

Open tool