YAML ⇄ JSON Converter

YAML and JSON: the same data, two notations

YAML and JSON are the two most common human-editable data formats in modern software. They represent the same kinds of values — strings, numbers, booleans, nulls, arrays, and key-value maps — but with different visual conventions. JSON uses braces, brackets, commas, and double-quoted keys. YAML uses indentation, dashes, and unquoted keys. Every JSON document is (by design) a valid YAML document. Most YAML documents can be losslessly converted to JSON.

Developers end up converting between the two constantly: Kubernetes, Helm, Docker Compose, GitHub Actions, GitLab CI, Ansible, CloudFormation, and half of DevOps tooling prefers YAML for human editing. Backends, APIs, and browsers prefer JSON for wire format. Translating between them is a recurring chore that deserves a fast, private tool.

Example — the same data in both formats

YAML:

name: Deftkit
version: 1.0.0
authors:
  - Alice
  - Bob
features:
  dark_mode: true
  max_items: 100
  endpoints:
    - /api/v1
    - /api/v2

JSON:

{
  "name": "Deftkit",
  "version": "1.0.0",
  "authors": ["Alice", "Bob"],
  "features": {
    "dark_mode": true,
    "max_items": 100,
    "endpoints": ["/api/v1", "/api/v2"]
  }
}

Both represent exactly the same object. The YAML version is slightly more readable for humans; the JSON version is what most programs parse natively.

How to use this converter

1. Choose a direction: YAML → JSON or JSON → YAML
2. Paste your source on the left
3. The converted output appears on the right instantly — no button to click, parsing is live
4. Click Swap sides to flip the direction and move the current output into the input box
5. Click Sample to load a representative example in the current direction
6. Click Copy to put the output on your clipboard

Under the hood

Conversion uses the js-yaml library running in your browser. For YAML → JSON, the input is parsed into a plain JavaScript object tree and then stringified with JSON.stringify with 2-space indentation. For JSON → YAML, the input is parsed with the built-in JSON.parse and then serialized via yaml.dump with 2-space indentation and a 100-column line width.

YAML anchors and aliases (&name and *name) are NOT emitted in the output by default. This is intentional — anchors let YAML avoid repeating the same subtree, but they confuse consumers that expect plain flat data. If your input uses anchors on the read side, the parser expands them; on the write side, duplicate subtrees are emitted in full.

What this tool does and does not do

• Does: convert between YAML 1.2 (and most YAML 1.1) and JSON, handling nested objects, arrays, strings, numbers, booleans, and nulls. Reports parse errors with line and column information when the parser can provide them
• Does: preserve key order in most cases. JSON has no concept of "ordered keys" in the spec but every modern engine keeps insertion order, and YAML roundtrips maintain it
• Does not: validate against a JSON Schema or YAML schema. That's a separate problem
• Does not: preserve YAML comments. Comments are not representable in JSON, so a round-trip through JSON will drop them. This is a fundamental limitation, not a bug — if you need comment-preserving YAML edits, use a dedicated YAML editor
• Does not: handle YAML's more exotic features (custom tags, typed scalars beyond the YAML 1.2 core schema, merge keys in all edge cases). The common cases work; the weird ones might not

Common YAML gotchas

• The "Norway problem": country: NO in YAML 1.1 parses the country as the boolean false because NO is an alias for no. YAML 1.2 fixed this. Modern parsers mostly use 1.2 (including this tool's default), but older tools may still hit the bug. Quote suspicious short strings: country: "NO"
• Leading zeros: In YAML, version: 011is parsed as an octal number (9 in decimal) in YAML 1.1. In YAML 1.2 and JSON, it's either an error or a decimal depending on the parser. Quote version strings to be safe
• Timestamps: YAML has a native timestamp type (2024-04-08T12:34:56Z) that JSON doesn't. When converting YAML→JSON, timestamps become ISO strings. Converting back produces strings, not timestamps, losing the type
• Indentation matters: YAML uses whitespace for structure. A single tab or mismatched space count will change the meaning. This tool's parser reports line numbers so errors are findable
• Tabs are forbidden: YAML does not permit tab characters for indentation. Paste YAML that was accidentally converted to tabs and the parser will reject it

The Norway problem, explained properly

The single most famous YAML bug. It has its own Wikipedia mention, its own stack of GitHub issues, and a decade of production incidents caused by it. Every YAML user should know what it is, and every YAML tool should handle it — this tool does, but most older tools don't.

The story: YAML 1.1 treats a surprising number of bare words as boolean values. All of these are true:

y, Y, yes, Yes, YES,
true, True, TRUE,
on, On, ON

And all of these are false:

n, N, no, No, NO,
false, False, FALSE,
off, Off, OFF

Notice NO in the second list. That is the ISO 3166 country code for Norway. A naive YAML 1.1 parser reading this config:

countries:
  - FR
  - DE
  - NO
  - SE

...produces this in-memory object:

{ "countries": ["FR", "DE", false, "SE"] }

Norway silently disappears, replaced by the boolean false. Any downstream code that iterates and compares strings crashes or produces silently wrong data. The bug is notoriously hard to debug because the YAML file looks correct, the parser throws no error, and the problem only surfaces when something downstream tries to use the Norwegian string and finds a boolean instead.

The same problem affects ON (usually meaning the Canadian province Ontario), Y (a valid first initial), and any configuration that stores short uppercase strings without quoting them.

The fix

1. Use a YAML 1.2 parser. YAML 1.2 removed all of these aliases except true and false. NOis now parsed as the string "NO". This tool uses js-yaml, which defaults to YAML 1.2 schema, so the Norway problem does not apply to the conversions you do here
2. Quote suspicious strings. When in doubt, wrap short uppercase strings in quotes: country: "NO". Quoting forces the parser to treat the value as a string regardless of alias rules
3. Avoid YAML 1.1 tools. The canonical bad actors are PyYAML (pre-6.0), older Ruby YAML libraries, and a handful of legacy Go parsers. Modern replacements (PyYAML ≥6.0 with yaml.safe_load, ruamel.yaml, go-yaml v3) all default to 1.2 schema

YAML 1.1 vs YAML 1.2 — what actually changed

YAML 1.2 was published in 2009 as a backward-incompatible cleanup of YAML 1.1. The changes that affect real-world parsing:

• Boolean aliases shrunk. YAML 1.2 only recognizes true and false (both lowercase) as booleans. Everything else (the Norway problem list above) is now a string
• Octal number syntax changed. YAML 1.1 used C-style leading-zero octal: 0755 parsed as 493. YAML 1.2 requires the 0o prefix: 0o755. In 1.2, 0755is either the string "0755" or a decimal 755 depending on the parser. This bit every Unix admin who copied mode: 0644 from legacy configs
• Hex/binary prefixes unchanged: 0x still works for hex, 0b still works for binary in both versions
• Unicode handling formalized. YAML 1.2 requires parsers to handle UTF-8, UTF-16, and UTF-32 with auto-detection via BOM. YAML 1.1 left encoding discovery vague
• JSON compatibility explicit. YAML 1.2 explicitly declares itself a superset of JSON. 1.1 did not make this guarantee; some edge cases (quoted numbers, empty objects) parsed differently

Most modern YAML tools use 1.2 by default. The exceptions are legacy systems that have not updated their YAML library in years. If you inherit an old config file, its semantics might be YAML 1.1 even if your new parser is 1.2 — which is exactly how old Ansible playbooks and Rails configs bite people.

Multi-line string styles, from scratch

YAML has four different ways to write a multi-line string. All four mean different things. Getting them wrong is the second most common YAML bug after the Norway problem.

Literal block scalar (|)

Preserves every newline exactly as written. Use for code blocks, ASCII art, and anything where line breaks matter.

script: |
  echo "hello"
  echo "world"
  exit 0

# Parsed value:
# "echo \"hello\"\necho \"world\"\nexit 0\n"

Folded block scalar (>)

Joins lines with spaces instead of newlines — like unwrapping a paragraph. Blank lines become single newlines. Use for prose that you want to wrap naturally in the source but render as flowing text.

description: >
  This is a long description
  that spans multiple lines
  but should render as one
  continuous paragraph.

# Parsed value:
# "This is a long description that spans multiple lines but should render as one continuous paragraph.\n"

Chomping indicators (|-, |+, >-, >+)

The trailing newline is controlled by a chomping indicator:

• | (default) — clip: keep a single trailing newline, strip the rest
• |- — strip: remove all trailing newlines
• |+ — keep: preserve every trailing newline as written

The difference between | and |- is whether the string ends with a \n. For shell scripts (where the extra newline is usually fine) the default is correct; for string comparisons in tests it matters, and omitting the strip indicator is a classic source of CI-only failures.

Quoted strings

Single-quoted strings are literal — no escape sequences, not even \n. To embed a single quote, double it: 'can''t'. Double-quoted strings support C-style escapes: "line1\\nline2". Prefer single quotes for values that contain no special characters — it's faster to read and has fewer footguns.

Privacy

All parsing and conversion happens in your browser via the js-yaml library and the native JSON.parse. Your data never leaves your device — no upload, no log, no analytics on the content. Safe for configuration files containing internal hostnames, secrets, or other data you would not paste into a random online converter.

Frequently asked questions

Is every valid YAML also valid JSON?

No — it's the other way around. Every valid JSON is valid YAML (YAML is a strict superset of JSON). Most YAML documents, though, use features that don't round-trip: comments, multi-line strings with special folding rules, anchors and aliases, custom tags, and non-string keys. Converting those to JSON loses some information.

Why did my converted YAML lose the comments?

JSON has no comment syntax, so any YAML → JSON conversion drops comments at the parse step. There's no way to round-trip comments through JSON. If you need to preserve comments across conversions, edit the YAML directly instead of using JSON as an intermediate.

Why does the converter emit quoted strings where my YAML had unquoted ones?

The YAML → JSON → YAML round-trip normalizes all strings. When converting back from JSON, the YAML writer quotes strings that would otherwise be ambiguous (like yes, on, null, or anything that could be interpreted as a number or boolean). Over-quoting is safer than under-quoting.

Can I convert YAML with multiple documents (---)?

Partial support. js-yaml parses the first document by default. For multi-document YAML files, this tool will show only the first document. Splitting a multi-doc YAML into individual files before converting is the cleanest workaround.

What's the difference between YAML and JSON in one sentence?

JSON is optimized for machines writing and parsing data; YAML is optimized for humans reading and editing it. Both encode the same universe of data values; they just draw the punctuation differently.

Is my data sent anywhere?

No — all parsing and conversion happens in your browser via js-yaml. Your YAML and JSON content never leaves your device.