JSON already does everything YAML does at the data-modeling level, both represent the same core structures: objects/mappings, arrays/lists, strings, numbers, booleans, and null. YAML exists not because JSON is functionally incomplete, but because JSON's syntax, while great for machines, is genuinely tedious for humans to write and read by hand, especially for large, deeply nested configuration files that people edit directly and frequently.
What YAML actually removes
YAML uses indentation to represent nesting instead of curly braces, so a nested object is expressed purely through consistent indentation rather than matching opening and closing brackets. It drops the requirement to quote every string, unquoted plain text is valid as long as it's unambiguous, and it drops trailing commas and comma separators between list items entirely, list items are just lines starting with a hyphen. YAML also supports comments (`#`), which JSON has no syntax for at all, a genuinely significant advantage for configuration files where explaining why a setting has a particular value matters.
The tradeoff for all that removed punctuation is that YAML's meaning depends entirely on exact, consistent indentation, a single misplaced space can silently change what a document means (or make it invalid) in a way that's much harder to spot visually than a missing JSON bracket, which is at least usually a hard parse failure rather than a silent misinterpretation.
Why JSON still wins for machine-to-machine data
JSON's explicit, unambiguous syntax is exactly why it dominates API responses and data interchange between programs: every value's type and boundary is stated directly by punctuation, there's no whitespace-sensitivity to get subtly wrong, and virtually every programming language has fast, battle-tested JSON parsing built in or trivially available. When data is being generated and consumed entirely by code, with no human expected to hand-edit it, JSON's slight verbosity costs nothing and its lack of ambiguity is a pure advantage.
YAML tends to win specifically for configuration files, Docker Compose, Kubernetes manifests, CI/CD pipeline definitions, because those files are written and edited by humans directly, often repeatedly, and the comments and reduced punctuation genuinely make a real difference to maintainability over time. If you're moving a file between contexts, say, a JSON API response you want to hand-edit as a config file, or a YAML config that needs to be sent as JSON, the YAML/JSON Converter handles the translation, and the JSON Formatter is useful for validating the JSON side once you're back in that format.
The gotcha that catches even experienced developers
YAML's unquoted-string convenience has a famous trap: the string `no` (or `yes`, `on`, `off`, `true`, `false` in various cases) is interpreted as a boolean by many YAML parsers unless explicitly quoted, which is why a country code field containing `NO` (Norway) has genuinely broken real config files by silently becoming the boolean `false`. This is exactly the kind of subtle correctness issue that JSON's mandatory quoting around every string avoids entirely, a real cost of YAML's readability convenience that's worth knowing before relying on unquoted values for anything that might coincidentally match a special keyword.