YAML to JSON Converter

Convert YAML to JSON in your browser

Paste YAML and get clean, pretty-printed JSON. This is handy when a tool wants JSON but your config — a Compose file, a CI workflow, an app settings file — is written in YAML, or when you simply want to inspect the exact data structure your YAML produces.

The data-model mapping

The converter is a small recursive-descent parser over indentation levels. It first tokenizes the input: tabs are expanded to two spaces, blank lines and # comment lines are dropped, and each remaining line is recorded with its indent depth and trimmed content. It then walks those lines:

• A run of lines that begin with - at the same indent becomes a JSON array (block sequence).
• Lines of the form key: value at the same indent become a JSON object (mapping).
• A key with an empty value followed by more-indented lines recurses into a nested block.

Scalars are typed: whole numbers become JSON numbers, decimals become floats, true/false become booleans, null and ~ become null, an inline [a, b] becomes an array, and quoted values stay strings. The result is pretty-printed with 2-space JSON indentation.

Example

Input:

name: Gera Tools
private: true
tools: 6
tags:
  - fast
  - free

Output:

{
  "name": "Gera Tools",
  "private": true,
  "tools": 6,
  "tags": ["fast", "free"]
}

Everything runs locally in your browser — your configuration and secrets are never uploaded or stored, so it is safe for sensitive files.

When you need YAML-to-JSON conversion

Debugging CI/CD configuration. GitHub Actions, GitLab CI, Bitbucket Pipelines, and CircleCI all define workflows in YAML. When a workflow fails in an unexpected way, converting the YAML to JSON and then inspecting the exact data structure can reveal subtle issues — for example, a boolean on that YAML parses as true instead of the string "on" that the pipeline engine expected.

Passing config to tools that require JSON. Many CLIs and API clients accept JSON config but not YAML. Convert once and pass the JSON object.

Checking what your Kubernetes or Helm chart actually becomes. YAML anchors and merge keys (<<) can produce surprising structures. Converting (for the parts this tool supports) gives a quick sense of the resolved data.

Common pitfalls to watch for

The on / off / yes / no trap. YAML’s boolean parsing is broader than most people expect. The values yes, no, on, off, true, and false (case-insensitive) all parse as booleans in the YAML 1.1 spec. So enabled: yes becomes {"enabled": true} in JSON. If you need the literal string "yes", quote it: enabled: "yes".

Unquoted strings that look like numbers. A value like version: 1.0 becomes {"version": 1} if the parser reads it as an integer, or 1.0 as a float depending on implementation. Quote numeric-looking strings that you intend as text: version: "1.0".

Tabs in YAML. YAML disallows tab characters for indentation — they cause a parse error. This converter expands tabs before parsing, but the underlying YAML would still fail in a strict loader. The YAML formatter companion tool can clean these up.

Implicit typing: the “Norway problem” and friends

The classic YAML surprise is that unquoted scalars are typed by guessing. Under widely deployed YAML 1.1 parsers, no parses as boolean false — so a country list containing Norway’s code NO becomes false in the JSON output. The same family of surprises: on/off become booleans, 3.10 becomes the number 3.1 (goodbye Python version), 012 may parse as octal 10, and an unquoted 12:30 can become a sexagesimal number in old parsers. YAML 1.2 (the current specification) removed most of these — it is also a strict JSON superset — but tooling ecosystems still mix 1.1 and 1.2 behaviour. The defence when a converted value looks wrong: quote the scalar in the YAML source and convert again; a quoted string is unambiguous in every YAML version and lands in RFC 8259 JSON as exactly the string you wrote. Converting to JSON is, usefully, the fastest way to discover these typing surprises — the JSON output shows you what the parser actually understood, with no implicit typing left to hide behind.

Anchors and aliases deserve a mention: YAML lets one node reference another (&defaults / *defaults), and conversion expands those references into plain copies, since JSON has no reference syntax. The output is therefore larger but self-contained — useful for seeing the effective configuration after all merges, which is often the very question that brought you to the converter.

Comments are the other one-way street: YAML files are usually annotated, JSON has no comment syntax at all, and every comment is dropped in conversion. Keep the YAML as the annotated source of truth and treat the JSON as a disposable, machine-facing view — regenerated on demand, never edited by hand.