YAML to JSON

Convert YAML configuration into valid JSON.

Indent

YAML Input

or drop a file here

JSON Output

{
  "name": "zeroserver",
  "private": true,
  "tags": [
    "fast",
    "client-side"
  ],
  "config": {
    "port": 3000,
    "ssl": false
  }
}

From YAML to JSON

This tool parses YAML — including nested mappings, sequences, anchors, and typed scalars — and serializes the result as JSON with your chosen indentation. It's the fastest way to feed a hand-written config file into an API, a JavaScript app, or another tool that only speaks JSON. Parsing happens locally; your configuration never leaves the browser.

Built and maintained by Meet Shah · Last updated 28 July 2026

What this tool is used for

Feeding a YAML config into a tool or an API that only accepts JSON.
Checking exactly how a YAML parser resolved your types and anchors.
Producing a JSON fixture from a manifest.
Comparing two YAML files by converting both and diffing the JSON.
Confirming that a value you wrote as a string did not become a number or a boolean.

How it works in practice

A worked example

A hand-written pipeline config needs to become JSON so a script can read it without adding a YAML dependency.

Input

service: billing
replicas: 3
ports:
  - 8080
  - 8443
env:
  LOG_LEVEL: debug
  FEATURE_X: "on"

Output

{
  "service": "billing",
  "replicas": 3,
  "ports": [
    8080,
    8443
  ],
  "env": {
    "LOG_LEVEL": "debug",
    "FEATURE_X": "on"
  }
}

Types came across without being asked for, which is the whole reason to parse rather than to translate line by line. The replica count is a number because it was written as one, the ports are numbers inside a real array, and the feature flag stayed the string it was quoted as — had those quotes been missing it would have arrived as a string too, since this parser follows the 1.2 core schema where the bare word is not a boolean. Structure, not text: nesting becomes nesting and the sequence becomes an array.

The edge case that catches people

This is stricter than the JSON it produces, in one respect that is genuinely useful. A repeated mapping key is refused outright — the parser stops with duplicated mapping key and the line and column — whereas a JSON parser accepts a duplicate silently and keeps whichever came last. So a config with an accidentally repeated key fails here and passes there, which makes a conversion an accidental audit. A tab used for indentation is rejected just as firmly, with the position named, since YAML forbids them outright.

When not to use this tool

It reads one document, and a great deal of real YAML is not one document. A file with separator lines between resources — the way Kubernetes manifests are usually packed — stops with expected a single document in the stream, but found more, and needs splitting first. Comments and anchors do not survive either, because the file is parsed into data and re-serialised, so anything maintained by hand should be converted to a copy rather than in place. For a template processed before a parser sees it, this is the wrong stage of the pipeline entirely.

Frequently Asked Questions

What is lost converting YAML to JSON?: Comments, permanently — JSON has no comment syntax, so every explanatory line in a config file disappears. Also anchors and aliases (they are expanded inline, so shared structure becomes duplicated) and multi-document files.
How are multi-document YAML files handled?: They cannot become one JSON document. A file with --- separators holds several documents, so the output must be a JSON array or NDJSON. A converter emitting only the first document silently discards the rest.
What happens to YAML-specific types?: They degrade. Dates become strings, since JSON has no date type; explicit tags like !!binary lose their meaning; and sets and ordered maps have no JSON equivalent, so they flatten to arrays or objects.
Do anchors survive?: No — they are RESOLVED, not preserved. A YAML file using an anchor once and referencing it ten times produces ten full copies in JSON, which can inflate the output dramatically and loses the intent.
Why does my value change type?: Because YAML coerced it before JSON ever saw it. Unquoted 1.10 is a float that becomes 1.1, an unquoted zip code loses its leading zero, and NO becomes false — the value was already wrong in the YAML parse.
How are YAML's non-string keys handled?: JSON keys must be strings, so a YAML mapping keyed by a number or a boolean is stringified — `true:` becomes `"true"`. Two distinct YAML keys can therefore collide into one JSON key.
What happens to a YAML timestamp?: It becomes a string, since JSON has no date type. That is usually harmless, but a consumer expecting a native date now needs to parse it — and the format YAML emitted may not be the one it expects.

Common errors and gotchas

Being surprised by implicit typing, where `yes`, `null` and `1.10` become a boolean, a null and a rounded number.
Losing comments, which JSON cannot represent at all.
Expanding anchors and aliases into duplicated data, which is correct but can be far larger than expected.
Overlooking a multi-document file, where JSON has no equivalent of the document separator.
Assuming key order carries meaning through the conversion.