JSON ↔ YAML Converter

What is a YAML / JSON converter?#

YAML and JSON are two ways of writing the same kind of data — nested maps, lists, strings, numbers, booleans, and null. JSON is strict and punctuation-heavy (every string in double quotes, brackets everywhere); YAML trades those quotes and braces for indentation and dashes, which makes it readable enough that humans hand-write it for configuration files, CI pipelines, and container manifests.

You keep needing to cross between the two because different tools prefer different formats. A Kubernetes chart is authored in YAML but the API speaks JSON. A CI config is YAML; the linter you want to feed it to expects JSON. A teammate pastes a YAML blob into a chat; your script wants JSON.parse. Doing this by hand — re-indenting, re-quoting, swapping dashes for brackets — is exactly the kind of fiddly work that introduces a stray comma or a misaligned space, and then nothing parses.

This page converts in both directions in your browser. YAML to JSON when you need machine-friendly strictness; JSON to YAML when you want a config file a human can actually read. It parses with the YAML 1.2 core schema (no risky object instantiation), pins errors to an exact row and column, and refuses to fold long lines so the output stays diff-friendly.

How to use it#

1. Pick a direction from the two-button toggle at the top left of the toolbar:
   • YAML → JSON (the default): paste YAML on the left, get strict JSON on the right.
   • JSON → YAML: paste JSON on the left, get indented YAML on the right.
2. Choose the Indent — 2 or 4 spaces. This controls the output’s nesting depth on both sides.
3. Click Sample to load a short example if you want to see the behaviour before pasting your own data, or Clear to wipe both panes.
4. The right pane updates as the conversion runs. The status bar underneath reports one of three things: a success line with the output byte size, an empty-input hint, or a parse error with a 1-based row and column pointing at the exact offending token.
5. Click Copy on the output header to grab the result.

Conversion runs the moment the input parses. There is no Generate button to click — fix the input and the output refreshes.

Key features#

• Two-way, one pane pair. The same input/output layout handles both directions; the toggle decides which parser runs.
• YAML 1.2 core schema. null, true/false, integers, floats, and quoted strings all resolve exactly as a standard-compliant parser resolves them — not as a loose heuristic.
• Line folding disabled. Long output lines are never wrapped or elided, so a diff against a checked-in file shows only real changes.
• Exact error location. A misaligned indent or a stray : is reported as row:col, not as a generic “could not parse”.
• Depth-guarded. Deeply nested input (the classic “YAML billion-laughs” expansion) is capped, so a hostile or accidentally recursive file cannot freeze the tab.
• Local only. Your config never leaves the page — there is no backend to send it to. Past a megabyte, the heavy parse is handed to a background worker so the UI stays responsive.

Worked example#

A common real task: a service config written as YAML needs to go into a JSON request body. Paste this into the left pane with YAML → JSON and 2 indent selected:

name: api-gateway
port: 8080
replicas: 3
targets:
  - host: example.com
    port: 443
  - host: cdn.example.com
    port: 8443
features:
  retries: true
  timeout_ms: 2500

The right pane produces strict, parse-ready JSON:

{
  "name": "api-gateway",
  "port": 8080,
  "replicas": 3,
  "targets": [
    {
      "host": "example.com",
      "port": 443
    },
    {
      "host": "cdn.example.com",
      "port": 8443
    }
  ],
  "features": {
    "retries": true,
    "timeout_ms": 2500
  }
}

Notice the unquoted YAML values 8080, true, and 3 became a JSON number, boolean, and number respectively — the core schema typed them, you did not have to. Reverse the direction (JSON → YAML) and paste the JSON back: you get the same nested structure re-indented with dashes for list items, which is the form you would check into a config repository.

FAQ#

Are my YAML comments preserved through the round trip?#

No. JSON has no comment syntax at all, so any # comment in your YAML is read and then dropped on the way to JSON — there is simply nowhere to put it. Comments are tolerated on input (they never cause an error), but they cannot survive the crossing. If comments matter, keep the YAML as the source of truth and generate JSON from it each time.

Does it handle multi-document YAML (files separated by ---)?#

It processes the document stream and returns the leading document. Most config and manifest files are single-document, so this is rarely an issue; if you have a multi-document stream, split it on the --- separators and convert each part.

YAML or JSON for my config file — which should I pick?#

Use YAML when a human edits it by hand and you want comments-ish readability with anchors and nesting by indent. Use JSON when a machine produces it and a parser consumes it, or when strictness matters (JSON has exactly one legal way to write each value, so there is no ambiguity to debug). This tool exists so you do not have to commit to just one.

The error says “row 4, col 5” but that line looks fine. What is wrong?#

Almost always indentation. YAML decides structure from leading spaces, so a child that is one space too far left or right — or mixed tabs and spaces — surfaces as an error on the line after the real culprit, because the parser only notices the inconsistency when it reads the next token. Check the indent of the line above the reported row first.