YAML
Also known as: YAML Ain't Markup Language, YML
YAML is a text format for writing structured data, mainly configuration files, that uses indentation and simple dashes instead of brackets and quotation marks.
It's widely used in DevOps and cloud tools such as Kubernetes, GitHub Actions, Docker Compose, and Ansible. YAML is easy to read and allows comments. While it's friendlier than JSON for humans, its reliance on precise indentation and some surprising automatic type conversions can cause hard-to-spot errors.
YAML, explained at three levels
At home
YAML is like a tidy outline, where indentation shows which items belong under which heading. Each line gives a setting name, a colon and a value, and anything indented beneath it belongs to that setting. Dashes mark lists. Programs read the outline to learn their settings, which is why a single misplaced space can change what the program thinks you meant.
At work
YAML is a text format for writing configuration files, the settings that tell software how to run. It uses indentation and simple dashes instead of brackets, so people can read and edit it easily, and it allows comments. Businesses care because many cloud, automation and deployment tools are configured in YAML, so a small mistake in one file can change or break a live system.
At home
YAML describes structured data using indentation instead of brackets. A setting name, a colon and a value make one entry, and lines indented beneath it belong to it, so the layout of the text is the structure. Lists use dashes. That makes YAML easy for people to read and edit, which is why tools such as Docker Compose, Kubernetes and GitHub Actions use it for configuration. The catch is that a single wrong space changes the meaning.
At work
YAML supports comments, nested mappings, lists, multi-line strings and anchors that let one block reuse another. It is a superset of JSON, so most JSON is valid YAML. Because indentation defines structure and tabs are not allowed, store YAML in version control and validate it with linters such as yamllint and schema checks in CI pipelines. Many tools, such as Helm, generate YAML from templates, which adds another layer to check.
At home
YAML guesses types from unquoted values, and older parsers guess in surprising ways. Under YAML 1.1 rules, 'no' can become false, so the country code NO for Norway turns into a boolean, a problem nicknamed the Norway problem. Numbers with leading zeros may be read as octal, and version numbers like 1.10 can become 1.1. In my view, putting text values in quotation marks avoids nearly all of these surprises.
At work
Some YAML libraries can construct arbitrary objects from tags, so loading untrusted YAML has led to remote code execution, for example with Python's yaml.load and Java's SnakeYAML. Always use safe loading functions. Prefer YAML 1.2 parsers, which drop most implicit type surprises. In infrastructure pipelines, render templates and validate the final output against schemas, such as Kubernetes API schemas, and use policy tools like OPA or Kyverno before deployment.
Real-world examples
At home
Carlos set up a home automation system configured with YAML. A single misaligned space broke it until his editor highlighted the error.
At work
Nadia manages Kubernetes for a Toronto startup. She added YAML linting to every pull request after a typo took down a service.
How it compares
| feature | YAML | JSON |
|---|---|---|
| Structure | Indentation | Braces and brackets |
| Comments | Yes | No |
| Common use | Configuration | Data exchange |
| Error risk | Whitespace mistakes | Punctuation mistakes |
YAML is easier to read. JSON is easier for machines to parse.
For analysts
Where configuration lives in YAML, I'd require review and automated validation. Configuration errors cause a large share of production outages.
History & origin
Clark Evans, Ingy döt Net, and Oren Ben-Kiki created YAML in 2001. Its name originally meant 'Yet Another Markup Language' but was changed to the recursive 'YAML Ain't Markup Language' to emphasize data over documents. YAML 1.2, published in 2009, aligned it more closely with JSON, making most JSON valid YAML. The rise of DevOps, configuration management, and Kubernetes in the 2010s made YAML ubiquitous, with some engineers joking that their job had become 'YAML engineering.' A famous quirk, the 'Norway problem,' saw older YAML parsers read the country code NO as 'false.' In my view, YAML is pleasant to read and painful to debug.