A lot of infrastructure tooling (Kubernetes, Docker Compose, GitHub Actions, Ansible) reads YAML rather than JSON, even though the two formats are structurally equivalent. This is the quick fix when you have a JSON config, perhaps generated by a script or exported from an API, and need it in the YAML a tool actually expects, preserving nesting, arrays, and types exactly.
YAML is a superset, so this direction always works
Every valid JSON document is already valid YAML, which makes this conversion safe in a way the reverse is not. What changes is the syntax: braces and brackets give way to indentation, quotes around keys become optional, and commas disappear. The data underneath is identical.
The appeal is readability at depth. A deeply nested JSON config spends a lot of its width on punctuation and closing brackets, and YAML spends that width on the values instead. This is why Kubernetes manifests, CI pipelines, Docker Compose files and Ansible playbooks settled on it.
The things YAML will surprise you with
Indentation carries meaning, so whitespace is no longer cosmetic and a stray space can change which object a key belongs to. Tabs are not allowed as indentation at all. That strictness is the price of the readability.
Then there is the type guessing. Older YAML parsers interpret unquoted no as a boolean, which famously turns the country code for Norway into false, and read a value like 1.20 as the number 1.2, dropping the trailing zero from a version string. A version number written as 1.10 can be read as 1.1. Quote anything that is meant to stay a string. And note that the conversion cannot invent what JSON never had: YAML supports comments and anchors, but nothing in your JSON source can produce them.