Developer Runs locally Ready to use Built-in examples No tracking

YAML and JSON Converter

YAML to JSON parses indentation, "- " sequences, [] {} flow style and | > block scalars, ignoring comments; JSON to YAML re-emits valid YAML and quotes strings that would otherwise read as numbers or booleans.

YAML and JSON describe the same data structure in different notations: YAML expresses hierarchy through indentation and dashes, reads like a list, and is the default for Kubernetes manifests, CI pipelines, Docker Compose and configuration files generally; JSON is strict and easy for machines to parse, and is the common format for APIs and debugging tools. The two need converting back and forth constantly.

The pitfalls cluster in three places. Indentation: YAML forbids tabs, and one level of misalignment changes the meaning. Quoting: version: 1.0 and version: "1.0" are a number and a string respectively, so this tool quotes strings that would otherwise read as numbers or booleans when emitting YAML. And features: anchors, aliases, custom tags and multiple documents need a stateful parser, so they are reported as unsupported rather than turned into a wrong result.

—
—
—
—

How to use

  1. Choose the direction: YAML to JSON, or JSON to YAML.
  2. Paste the source and read the converted output.
  3. Check that number-like and boolean-like strings are quoted.
  4. Remember anchors, aliases and multi-document files are reported as unsupported.

How it works

Indentation drives the structure

YAML expresses hierarchy through indentation with no braces as a safety net, so indent mistakes change meaning directly: same-level items must align and children must indent deeper. The parser builds a stack by indent column — same level closes the parent, deeper descends — and Tab indentation errors out immediately: the YAML spec forbids Tabs in indentation, and mixing Tabs with spaces is the classic config-file trap.

Literal | vs. folded > blocks

| is a literal block: every newline inside is kept — right for scripts, certificates, multi-line SQL. > is a folded block: single newlines collapse to spaces and only blank lines produce newlines — right for long descriptive sentences. Both take chomping indicators: - strips the trailing newline, + keeps all of them, and nothing keeps exactly one.

What advanced syntax is unsupported

Anchors & / aliases * / tags !!str / multi-document --- separators are unsupported — they require a stateful parser with a reference graph, and this tool's purpose is straightforward config interconversion. Such syntax reports an explicit unsupported-syntax error rather than a wrong conversion.

Code example

Shell Converting on the command line (yq) 

# YAML to JSON
yq -o=json '.' deploy.yaml > deploy.json

# JSON to YAML
yq -o=yaml '.' deploy.json > deploy.yaml

# Read a single field instead of converting the whole file
kubectl get deploy myapp -o yaml | yq '.spec.template.spec.containers[].image'

Python Always use safe_load 

import json, yaml

# safe_load is required: yaml.load can execute arbitrary tags and is unsafe
with open("deploy.yaml", encoding="utf-8") as f:
    data = yaml.safe_load(f)

with open("deploy.json", "w", encoding="utf-8") as f:
    json.dump(data, f, ensure_ascii=False, indent=2)

# JSON to YAML: allow_unicode, otherwise non-ASCII becomes escape sequences
print(yaml.safe_dump(data, allow_unicode=True, sort_keys=False))

FAQ

How many spaces should YAML indentation use?

No fixed rule — just stay consistent within a file; the community convention is 2 spaces. What's truly forbidden is Tab: the spec bars it from indentation, and it errors on sight. If your editor auto-indents, set the file to spaces-only.

Why does my copied YAML report indentation errors?

Usually fullwidth or non-breaking spaces smuggled in from a web page or chat window. Only halfwidth spaces count as indentation here — Tabs or other whitespace error out. Normalize whitespace to halfwidth spaces in an editor before pasting.

Why can't anchors and aliases convert?

Anchor &name and alias *name mean "reference the same data", which expands to shared object references — and JSON has no references. Forcing expansion would loop forever on circular references. Rather than output something that looks right but means something else, the tool reports unsupported syntax.

What about multiple documents separated by ---?

A leading --- is ignored as a document-start marker; another --- mid-file (true multi-document) reports unsupported. Split multi-document files and convert them separately.

Do | and > blocks survive the round trip?

Content is preserved but form isn't: inside JSON the newlines are ordinary characters (\n), and converting back to YAML this tool uniformly emits double-quoted strings with \n escapes rather than re-guessing | or > — a folded block restored as a literal block isn't equivalent, and escaped strings are the least surprising output.

Will a # inside a value start a comment?

Only a # at line start or preceded by whitespace comments; a # hugging content (url: http://x/#a) belongs to the value. # inside quotes is always a plain character, and # inside block scalars is content too.

When does JSON-to-YAML quote a string?

For strings that wouldn't look like strings: pure numbers ("007"), boolean/null-lookalikes ("true", "null"), anything containing : or a space-before-#, leading/trailing whitespace, empty strings, and values starting with - ? # and friends. Quoting guarantees re-parsing still yields strings rather than numbers or booleans.

Is my configuration sent to a server?

No. Parsing and serialization run entirely in the browser with no network requests — the server never sees your config. No history is written; closing the page clears it. Database connection strings and keys are safe here.