Why would I convert JSON to YAML?

YAML is far easier to read and write for configuration files because it uses indentation instead of braces and brackets, supports comments (which JSON does not), and requires less punctuation. Tools like Kubernetes, Helm, Docker Compose, Ansible, and GitHub Actions all use YAML for their configuration files.

Are there any data types that do not convert cleanly between JSON and YAML?

JSON and YAML share the same core data model (strings, numbers, booleans, null, arrays, objects), so standard data converts cleanly in both directions. YAML-specific features like anchors, aliases, and multi-line strings have no JSON equivalent and are simplified during YAML → JSON conversion.

Does the converter preserve the order of keys?

Yes. The converter preserves the original key order when converting in both directions. This matters for diff readability in version-controlled configuration files where a change in key order would produce a noisy, misleading diff.

JSON to YAML Converter — Both Directions

Round-trip between JSON and YAML with configurable indentation. Every JSON document is valid YAML; the interesting problems run the other way.

Input

Paste your JSON here, or drag a file…

Drag & drop a file, or paste content above

Output

Output will appear here

The Norway problem

YAML 1.1 infers types from unquoted scalars, and the boolean rules are far broader than anyone expects. y, Y, yes, Yes, YES, n, N, no, No, NO, on, On, ON, off, Off and OFF all parse as booleans.

Which means a list of ISO country codes does this:

countries: [GB, FR, NO, DE] → ["GB", "FR", false, "DE"]

Norway becomes false. This is the famous case, but it is not the only one. Version numbers lose trailing zeros because 1.20 is the number 1.2. Times like 12:30 parse as sexagesimal integers in YAML 1.1. A MAC address or a git SHA that happens to be all digits becomes a number. And null, Null, NULL and ~ are all null.

The fix is unglamorous and absolute: quote any scalar whose exact textual form matters. YAML 1.2 narrowed the boolean set to just true/false, but most parsers in production — including PyYAML's default loader — still implement 1.1.

What each format is good at

	JSON	YAML
Comments	None	Yes — the main reason config uses YAML
Whitespace	Insignificant	Significant — indentation defines structure
Tabs for indentation	Fine	Forbidden — spaces only
Type inference	None — types are explicit	Aggressive, and a frequent source of bugs
Multi-line strings	Escaped \n only	Block scalars with `\|` and `>`
Reuse	None	Anchors (`&`) and aliases (`*`)
Multiple documents per file	No	Yes, separated by `---`
Parse speed	Very fast	Considerably slower
Attack surface	Minimal	Real — see the note below
Best for	APIs, data interchange	Hand-edited configuration

YAML features with no JSON equivalent

Converting YAML to JSON necessarily discards these. That is worth knowing before treating the conversion as lossless.

Block scalars — readable multi-line strings

# | preserves newlines
script: |
  #!/bin/bash
  set -euo pipefail
  echo "deploying"

# > folds newlines into spaces
description: >
  This becomes a single long line
  when parsed, which is useful for
  wrapping prose in a config file.

Anchors and aliases — reuse without repetition

defaults: &defaults
  adapter: postgres
  pool: 5
  timeout: 30

development:
  <<: *defaults        # merge key
  database: app_dev

production:
  <<: *defaults
  database: app_prod
  pool: 20             # override

# Converting to JSON expands all of this,
# so the repetition comes back.

Quoting: what to quote and why

# Wrong — all of these are coerced
country: NO           # -> false
version: 1.20         # -> 1.2
time: 12:30           # -> 750 in YAML 1.1
sha: 8834920          # -> number, loses leading zeros
empty: null           # -> null, not the string "null"

# Right
country: "NO"
version: "1.20"
time: "12:30"
sha: "8834920"
empty: "null"

About

The JSON ⇄ YAML Converter transforms JSON data to YAML format and back, making it easy to work with configuration files for Kubernetes, Docker Compose, GitHub Actions, and other tools that prefer YAML. The converter preserves data types, arrays, and nested objects faithfully in both directions.

How to use

1 Paste your JSON in the left panel to convert it to YAML on the right.
2 Switch direction to paste YAML and get JSON back.
3 Copy the result or compare both representations side by side.

Why would I convert JSON to YAML?: YAML is far easier to read and write for configuration files because it uses indentation instead of braces and brackets, supports comments (which JSON does not), and requires less punctuation. Tools like Kubernetes, Helm, Docker Compose, Ansible, and GitHub Actions all use YAML for their configuration files.
Are there any data types that do not convert cleanly between JSON and YAML?: JSON and YAML share the same core data model (strings, numbers, booleans, null, arrays, objects), so standard data converts cleanly in both directions. YAML-specific features like anchors, aliases, and multi-line strings have no JSON equivalent and are simplified during YAML → JSON conversion.
Does the converter preserve the order of keys?: Yes. The converter preserves the original key order when converting in both directions. This matters for diff readability in version-controlled configuration files where a change in key order would produce a noisy, misleading diff.

More in Format Converters

CSV ⇄ JSON Converter Converts in both directions with correct RFC 4180 quoting, custom delimiters, header row control, and optional type inference for numbers and booleans.

See all format converters.