Two formats for the same data
YAML and JSON both represent structured data — objects, arrays, strings, numbers — and either can be converted to the other without loss in most cases. They exist because they optimise for different readers.
JSON is designed to be generated and parsed by machines. Its rigid punctuation of braces, brackets and quotes is unambiguous but visually dense. YAML is designed to be written and read by humans, using indentation instead of braces and dispensing with most quotes, which makes configuration files considerably cleaner.
Why configuration moved to YAML
Almost every modern infrastructure tool uses YAML for configuration — Docker Compose, Kubernetes, GitHub Actions, Ansible and countless others. The reason is readability at scale. A Kubernetes deployment written in JSON is a wall of nested braces; the same deployment in YAML is a clean indented outline that a human can scan and edit confidently.
Converting between the two is a routine need: pasting a JSON API response into a YAML config, or converting a YAML file into JSON for a tool that expects it.
The indentation trap
YAML's greatest strength is also its most notorious weakness. Because structure is defined purely by indentation, a single misplaced space changes the meaning or breaks the file entirely — and the error can be invisible, since spaces and tabs look identical on screen.
YAML forbids tabs for indentation precisely because mixing them with spaces causes chaos, but editors that insert tabs automatically catch people out constantly. If a YAML file will not parse and looks correct, misaligned indentation or a stray tab is almost always the cause. Converting to JSON and back is one way to normalise the whitespace.
Things YAML does that JSON does not
YAML supports comments, which JSON famously does not — a significant advantage for configuration files that need explaining. It has anchors and references that let you reuse a block of configuration without repeating it. It handles multi-line strings gracefully. And it does not require quotes around most strings.
That last convenience causes a well-known pitfall. YAML interprets certain unquoted values in surprising ways: the word "no" becomes the boolean false, a version number like 1.20 loses its trailing zero as a number, and a value like "22:22" may be read as a time rather than a string. When a value must be treated literally, quote it. This is why converting complex YAML to JSON occasionally reveals a value that was not what its author intended.
Which to use
Use JSON for data moving between programs and for anything a machine generates. Use YAML for configuration that humans write and maintain, where readability and comments matter. Many projects use both, and converting between them is simply part of the workflow.
Converted in your browser
Conversion happens locally using a JavaScript YAML parser. Nothing is transmitted, which matters since config files routinely contain secrets and connection details.
Frequently Asked Questions
Why do infrastructure tools use YAML?
Readability at scale. A complex configuration is far easier to scan and edit as an indented YAML outline than as nested JSON braces.
Why does my YAML fail to parse?
Almost always indentation — a misaligned space or a stray tab. YAML forbids tabs for indentation, and the error is often invisible on screen.
What can YAML do that JSON cannot?
Comments, anchors for reusing blocks, cleaner multi-line strings, and unquoted values. JSON supports none of these natively.
Why did a value change when I converted?
YAML interprets some unquoted values unexpectedly — "no" becomes false, and numbers can lose trailing zeros. Quote values that must stay literal.
Is my config uploaded?
No. Conversion runs entirely in your browser, which matters since config files often contain secrets.