JSON ↔ YAML Converter

Spaces only — never tabs

YAML structure is defined entirely by indentation, and the spec forbids tab characters for indentation. A single tab pasted from another editor produces a parser error that points at the wrong line. If a hand-written YAML file "won't parse" for no visible reason, search for tabs first.

Block scalars: | keeps newlines, > folds them

This is the single most useful YAML feature that JSON lacks. A literal block | preserves every line break; a folded block > joins lines with spaces. Both convert to a JSON string with the appropriate \n characters.

script: |
  echo "line one"
  echo "line two"

# becomes JSON:
# "script": "echo \"line one\"\necho \"line two\"\n"

Add a - (|-) to strip the final newline, or a + (|+) to keep all trailing newlines.

Anchors (&) and aliases (*) get expanded on the way to JSON

YAML lets you define a block once with an anchor and reuse it with an alias. JSON has no such concept, so converting to JSON inlines the value into every place it was referenced — the DRY-ness is lost but the data is identical.

defaults: &base
  retries: 3
prod:
  <<: *base
  retries: 5

# JSON inlines it: prod = { "retries": 5 }

A maliciously nested alias chain is the basis of the "billion laughs" expansion attack — another reason never to parse untrusted YAML with a full-power loader.

Duplicate keys are silently allowed by some parsers

JSON objects can technically repeat keys (last wins), and several YAML parsers do the same instead of erroring. If two keys collide, the second value overwrites the first with no warning — a common cause of "my config setting is being ignored."

Why did my YAML value no turn into false?

This is the "Norway problem." In YAML 1.1, the unquoted scalars no, yes, on, off, true, and false are all resolved to booleans before they ever reach your application. The two-letter ISO code for Norway is NO, so a country list written without quotes loses Norway to false. Fix it by quoting the value: country: "no".

Why does my version number 1.20 become 1.2?

An unquoted 1.20 is type-resolved as a float, and floats drop trailing zeros, so it becomes 1.2. Worse, 1.10 sorts below 1.9 numerically. Always quote version strings, image tags, and any "number" you intend to compare as text: version: "1.20".

Is converting JSON to YAML lossless?

Yes. Because JSON is a subset of YAML, every JSON document converts to YAML without losing data or changing types. The reverse (YAML → JSON) is lossy only for things JSON cannot represent: comments are dropped, and anchors/aliases are expanded inline. The actual key/value data is always preserved.

Why does my YAML fail to parse when JSON with the same data works?

Three usual suspects: (1) a tab character used for indentation — YAML forbids tabs; (2) inconsistent indentation where sibling keys don't line up at the same column; or (3) a value starting with a special character like {, [, @, %, or : that needs quoting. JSON is brace-delimited so none of these matter there.

How do I write a multi-line string in YAML?

Use a block scalar. | (literal) keeps every newline exactly; > (folded) joins lines with single spaces and preserves blank lines as breaks. Add - to chomp the trailing newline (|-). Converting back to JSON turns the whole thing into one string with embedded \n escapes — which is why a shell script in a GitHub Actions step uses run: |.

Is my data sent anywhere when I convert it?

No. This site is a static export with no backend, and the conversion runs entirely in your browser's JavaScript engine. You can confirm it in DevTools → Network: converting triggers zero outbound requests. That said, never paste secrets from a production Kubernetes Secret manifest into any online tool — strip them first.