JSON ↔ YAML Converter
Convert JSON to YAML or YAML to JSON. Switch direction with the toggle then click Convert.
What actually happens to your data on the way through
This isn't a text-to-text transform — it's two full parses through different type systems. JSON → YAML parses your input into a JSON node tree, walks it converting JSON objects to dictionaries and JSON arrays to lists, and re-serializes that with YamlDotNet; YAML → JSON does the reverse through YamlDotNet's parser first. One side effect worth knowing: the YAML serializer here has alias generation explicitly turned off, so even if your JSON has the exact same nested object repeated at multiple keys, the YAML output won't use YAML's anchor-and-alias syntax (&anchor / *alias) to reference it once and reuse it — every repetition gets written out in full as independent, duplicated YAML blocks.
When to use JSON vs YAML
- JSON is the right choice for machine-to-machine communication (REST APIs, database documents, browser storage) because it is universally supported, unambiguous, and faster to parse.
- YAML is preferred for configuration files that humans read and edit frequently — Docker Compose, Kubernetes manifests, GitHub Actions workflows, Ansible playbooks — because its indentation-based structure is easier to scan without the noise of quotes and braces.
- Both formats represent the same data model. A JSON object directly corresponds to a YAML mapping, a JSON array to a YAML sequence, and scalar types map 1-to-1.
How to use this tool
- Select the conversion direction using the toggle: JSON → YAML or YAML → JSON.
- Paste your input into the editor on the left.
- Click Convert.
- Copy the result from the output panel on the right.
YAML syntax quick reference
| YAML | JSON equivalent |
|---|---|
key: value | {"key": "value"} |
count: 42 | {"count": 42} |
enabled: true | {"enabled": true} |
- item1 | ["item1", "item2"] |
nested: | {"nested": {"child": "value"}} |
null_val: ~ | {"null_val": null} |
How numbers keep their integer-vs-decimal identity
Going JSON → YAML, each scalar value is type-checked in a specific order: boolean first, then whole-number integer, then decimal, then string as the fallback. That ordering is what keeps "count": 42 coming out as the YAML integer 42 rather than a decimal — and what keeps "price": 19.99 coming out with its decimal point intact rather than getting rounded or reformatted. It also means a JSON number too large for a standard 64-bit integer falls through to the decimal branch rather than failing outright.
Why the YAML output always uses 2-space indentation
YamlDotNet's default serializer settings produce 2-space indentation regardless of how your original JSON was formatted — a deeply nested JSON object indented with tabs, or 4 spaces, or no whitespace at all (minified) converts to the same consistently-indented YAML output every time. That consistency is generally a feature, not a limitation: it means the YAML this tool produces matches the indentation convention used by Prettier, most Kubernetes and Docker Compose tooling, and the YAML style most CI linters expect by default — so the output is usually ready to paste into a config file without a reformatting pass first.
Common pitfalls when converting
- YAML reserved words —
yes,no,on,offare treated as booleans in some YAML parsers. Quote them explicitly if you mean the literal strings. - Indentation — YAML uses spaces, never tabs. Mixed indentation causes parse errors.
- Multi-line strings — YAML block scalars (
|for literal,>for folded) have no JSON equivalent and are flattened to a single string during conversion. - Duplicate keys — JSON technically forbids duplicate keys; YAML allows them but parsers usually keep only the last value. The converter will pass through the first definition.
- Comments — YAML supports
#comments; JSON does not. Comments are stripped during YAML→JSON conversion.
JSON input
{
"name": "DevToolsHub",
"version": 1,
"features": ["formatting", "conversion"],
"active": true
}Converted output
YAML result