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

The same data model

YAML’s data types match JSON’s: scalars (strings, numbers, booleans, null), sequences (arrays), and mappings (objects). The conversion is structural — same tree, different rendering.

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

becomes:

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

YAML 1.1 vs YAML 1.2 type coercion

The biggest source of YAML-to-JSON surprises:

country: NO              # YAML 1.1: false (boolean!)
                         # YAML 1.2: "NO" (string)
version: "1.10"          # both versions: "1.10" (string, because quoted)
version_unquoted: 1.10   # YAML 1.1 and 1.2: 1.1 (number — trailing zero dropped)
status: yes              # YAML 1.1: true; YAML 1.2: "yes"
date: 2025-01-15         # YAML 1.1 and 1.2: parsed as Date object in many implementations
empty:                   # YAML: null

YAML 1.1’s “Norway problem” — country: NO becomes the boolean false — is the most-cited example. YAML 1.2 fixed booleans (only true/false); but many parsers default to YAML 1.1 behavior.

A safe practice: when converting YAML to JSON, run through a parser that explicitly uses YAML 1.2 semantics. The tool above defaults to YAML 1.2.

Quoting strings

Always quote strings that look like other types:

country: "NO"            # explicit string
zip: "00501"             # leading-zero, would otherwise be number 501
date: "2025-01-15"       # explicit string, not a Date
empty_string: ""         # not null

Quoted strings are unambiguous; unquoted strings are subject to YAML’s type-detection heuristics.

Multi-document YAML

YAML files can contain multiple documents separated by ---:

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

JSON has no equivalent. The conversion options:

Convert only the first document. Lossy if there are more.
Convert to a JSON array of documents. [{"name": "Alice"}, ...]. Cleanest.
Convert to JSON Lines (NDJSON). One JSON object per line: {"name": "Alice"}\n{"name": "Bob"}\n.... Good for streaming consumers.

The tool above uses the array form when the input has more than one document, and plain JSON for a single document. For converting Kubernetes manifests or multi-resource configs, the array form is usually right.

YAML features that don’t survive

JSON can’t represent:

Comments. YAML’s # comment lines are discarded.
Anchors and aliases. &anchor / *anchor are resolved (the alias is replaced with the anchored value), so the duplicate structure ends up in JSON.
Tags and custom types. YAML’s !!str, !!int, !ruby/object, etc. are usually flattened to native JSON types.
Multi-line block scalars (| and > styles). These resolve to strings, but the original style is lost.

For round-trip-safe storage, JSON is the safer canonical form.

Anchors and aliases

defaults: &defaults
  timeout: 30
  retries: 3

production:
  <<: *defaults
  host: prod.example.com

staging:
  <<: *defaults
  host: staging.example.com

The &defaults defines an anchor; *defaults references it. <<: merges the anchored mapping into the current one.

After conversion to JSON:

{
  "defaults": { "timeout": 30, "retries": 3 },
  "production": {
    "timeout": 30,
    "retries": 3,
    "host": "prod.example.com"
  },
  "staging": {
    "timeout": 30,
    "retries": 3,
    "host": "staging.example.com"
  }
}

The aliases are resolved. The defaults still appear as a top-level key because they were declared in the YAML; some converters strip them. The tool above keeps them — delete the key afterwards if you don’t want it.

Block style vs flow style

YAML supports both:

# Block style
tags:
  - vip
  - active

# Flow style
tags: [vip, active]

Both convert to the same JSON. The flow style happens to look like JSON but is YAML — a YAML parser must process it.

Dates

date: 2025-01-15
datetime: 2025-01-15T14:00:00Z

YAML 1.1 parsers automatically convert these to Date objects. JSON has no date type; the converter has to decide:

Stringify the date back to ISO 8601: "2025-01-15".
Convert to a Unix timestamp (number): 1736899200.
Keep as an object with type info: {"_type": "date", "value": "2025-01-15"}.

The tool above stringifies to ISO 8601 by default — the most consumer-compatible choice.

When this is the right tool

Generating JSON from human-edited YAML config. YAML is edited; JSON is consumed.
Reading Kubernetes/CI/Docker Compose configs into a JSON-based pipeline.
Ad-hoc inspection of a YAML file when you want JSON’s tooling (jq, JSON.parse).
Validating a YAML file by converting to JSON and running a JSON Schema validator.

Common pitfalls

YAML 1.1 booleans. country: NO becomes false. Use YAML 1.2 or quote consistently.
Lost comments. YAML comments don’t survive. Document elsewhere or convert lossily.
Anchor expansion. Resolved anchors look like duplication. JSON has no anchor concept.
Encoding issues. YAML allows several encodings; UTF-8 is the modern default. Match input and output.
Tab characters. YAML forbids tabs in indentation. Editors that auto-tab break the YAML; ensure spaces only.
Multi-document files converted as single document. Easy to lose data. Always check the source.

For the reverse direction, see JSON to YAML. For YAML validation, YAML validator.

YAML to JSON Converter