JSON to YAML Converter

This tool converts JSON to YAML in your browser; nothing leaves your machine. For the reverse direction, see YAML to JSON.

YAML and JSON share a data model

YAML’s data types are the same as JSON’s: scalars (strings, numbers, booleans, null), sequences (arrays), and mappings (objects). The conversion is structurally trivial — the same tree, rendered differently.

JSON:
{
  "name": "Alice",
  "age": 30,
  "tags": ["vip", "active"],
  "address": {
    "city": "NYC"
  }
}

YAML:
name: Alice
age: 30
tags:
  - vip
  - active
address:
  city: NYC

YAML uses indentation (and optional - for sequences) instead of braces and brackets. Strings often don’t need quotes. Lines are unambiguous.

What YAML adds over JSON

• Comments. # this is a comment — YAML supports them; JSON doesn’t.
• Multi-line strings. Folded (>) and literal (|) block scalars for prose without all the \n escaping.
• Anchors and aliases. &anchor and *anchor for referencing repeated structures.
• Document separators. --- to put multiple documents in one file.
• Loose syntax. Strings often don’t need quotes; numbers and booleans are detected by appearance.

Conversion from JSON to YAML doesn’t introduce these features automatically — the tool above produces literal output that mirrors the JSON structure. To use anchors or comments, you have to edit by hand.

When YAML’s loose syntax bites

YAML’s “let me figure out the type” approach is convenient until it isn’t:

country: NO          # ⚠️ "NO" is a YAML 1.1 boolean (false), not the string "NO"
version: 1.10        # ⚠️ "1.10" is the number 1.1, not the string "1.10"
status: yes          # ⚠️ "yes" is true in YAML 1.1
date: 2025-01-15     # ⚠️ this is a Date object in many YAML parsers, not a string
empty:               # ⚠️ this is null, not the empty string

The country code “NO” parsing as boolean false is the most-cited example — the so-called “Norway problem.” YAML 1.2 fixed many of these (booleans only true/false, not yes/no); but YAML 1.1 parsers (still common) keep the old behavior.

A safe strategy when converting JSON → YAML: quote any string that looks like another type. The tool above does this conservatively for known dangerous patterns:

country: "NO"
version: "1.10"
status: "yes"
date: "2025-01-15"
empty: ""

Quoting prevents the auto-coercion. Result is unambiguous.

Indentation

YAML is indentation-sensitive (like Python). The default is 2 spaces; some style guides use 4. The choice doesn’t matter to parsers, but it must be consistent within a document.

Tabs are forbidden. A tab character in YAML is a syntax error in most parsers. The tool above always emits spaces.

Multi-document YAML

A single YAML file can contain multiple documents separated by ---:

---
name: Alice
---
name: Bob
---
name: Charlie

JSON has no equivalent. JSON to YAML with multiple input documents is undefined; the tool above produces a single document.

For multi-document use cases (Kubernetes manifests, multi-resource configs), you often want one document per top-level array element of the JSON input. That’s a transformation, not a conversion — handle it separately.

Block style vs flow style

YAML supports both indented (block) and JSON-like (flow) styles:

# Block style (the default and idiomatic)
tags:
  - vip
  - active

# Flow style
tags: [vip, active]

Flow style is more compact for small structures. The tool above always uses block style; switch short arrays to flow style by hand if you prefer it.

YAML allows mixing both within a document:

users:
  - name: Alice
    tags: [vip, active]      ← flow style for short array
  - name: Bob
    tags: [vip]

This is valid and often desirable for readability.

When YAML is the right output

• Configuration files. Kubernetes, GitHub Actions, GitLab CI, Docker Compose, Ansible — all YAML.
• Documentation. Comments and multi-line strings make YAML more readable for humans than JSON.
• Files edited by humans. YAML is more forgiving and more readable than JSON for hand-editing.

When JSON is better:

• Data interchange between programs. JSON is faster to parse and unambiguous.
• APIs. Universal support.
• Large datasets. Faster, smaller, no indentation traps.

For the reverse direction, see YAML to JSON. For other JSON conversions, JSON to XML, JSON to CSV.

Common pitfalls

• Strings that look like other types. Always quote suspect values when generating from JSON if the consumer is YAML 1.1.
• Trailing newlines and indent inconsistency. Most YAML parsers tolerate both, but consistent indentation prevents subtle bugs.
• Tabs. Don’t use them; they’re forbidden. Make sure your editor doesn’t auto-tab.
• Preserving key order. JSON parsers preserve insertion order (in modern implementations). YAML preservation is parser-dependent. If order matters, document it.
• Encoding. UTF-8 is the modern YAML default. UTF-16 with BOM works in some parsers but not all.
• Long strings. A 500-character JSON string becomes a 500-character YAML string on one line, which makes the YAML hard to read. Folded block scalars (> followed by indented prose) are the YAML idiom for long strings; conversion tools rarely produce them automatically.