YAML is a text format for writing structured data in a way people can read and edit. Instead of brackets and tags, it uses indentation, dashes for list items and key: value pairs, so a file looks much like an outline. YAML is a common format for configuration files in container platforms, CI/CD pipelines, cloud templates and network automation tools. The name is a recursive acronym, “YAML Ain’t Markup Language”, chosen to say that it describes data, not documents.
At a glance
- YAML is a plain-text format for structured data: lists, key-value pairs, text, numbers and true/false values.
- Structure comes from indentation, which makes files readable but sensitive to spacing.
- It allows comments, which makes it popular for configuration that people maintain by hand.
- It is common in infrastructure as code, container and network automation tools.
- YAML 1.2 was designed so that most JSON documents are also valid YAML.
What problem it solves
Software needs settings: which servers to build, which ports to open, which VLAN a switch port belongs to. Those settings can live in a vendor console, a spreadsheet or someone’s memory, which makes them hard to review, copy or roll back. Writing them in a structured text file solves that, as long as the format is easy for people to read and for machines to parse.
YAML aims at both. A file describing three branch routers or a container deployment reads almost like a list someone would write by hand, yet tools can load it directly into data structures. Because it supports comments, teams can explain why a value is set the way it is. And because it is plain text, it fits in version control, so every change has an author, a date and a diff.
How it works
Mappings, sequences and scalars. YAML has three building blocks. A mapping is a set of key: value pairs. A sequence is a list, usually written with a dash in front of each item. A scalar is a single value, such as a string, number or boolean.
Indentation. Nesting is shown by indenting with spaces. A key indented under another belongs to it. Tabs are not allowed for indentation, and inconsistent spacing is the most common cause of broken files.
Types. Parsers infer types from the text: 8080 becomes a number, true a boolean, hello a string. Quoting a value forces it to be a string. Type guessing is a known trap: older YAML 1.1 parsers read words such as no or off as false, and version numbers such as 1.10 can be read as the number 1.1.
Extras. YAML supports comments with #, multi-line text blocks, several documents in one file separated by ---, and anchors that let one section reuse another. Not every tool supports every feature in the same way.
Schemas. YAML itself does not say which keys a file must contain. Each tool defines what it expects, and many publish schemas that editors and pipelines use to validate files before they are applied.
When it matters for buyers
- Cloud and container platforms. Kubernetes manifests, many CI/CD pipelines and several infrastructure templates are written in YAML, so your team or provider will maintain YAML files. See our public cloud page for help choosing platforms.
- Network automation. Many automation tools store device inventories, variables and playbooks in YAML. If a provider automates your network, ask to see and keep those files.
- Handover and lock-in. Configuration kept as YAML in your own repository is portable. Configuration kept only in a provider’s tooling is not.
- Change control. A one-space mistake can break a deployment. Ask how files are validated and reviewed before they reach production.
Questions to ask vendors
- Which parts of our configuration will be stored as YAML, and where will those files live?
- Will we own the repository, and will we receive the files when the contract ends?
- How are YAML files validated before deployment: schema checks, linting, test environments?
- Which YAML version and parser does your tooling use, and how does it handle type guessing?
- Who reviews and approves changes, and how do we see the history of what changed?
- Do any files contain passwords or keys, and how are those secrets kept out of plain text?
How it differs from JSON
JSON and YAML describe the same kinds of data, and most JSON can be read by a YAML 1.2 parser. The difference is who they are written for. JSON uses braces, brackets and quoted keys, has no comments and is strict, which makes it the common choice for data exchanged between programs, such as API requests and responses. YAML drops most punctuation, uses indentation and allows comments, which makes it easier for people to write and review, at the cost of more ways to make a subtle mistake. XML, the third common format, uses opening and closing tags and is more verbose than either, but has mature schema and validation tools. In practice, teams often write configuration in YAML and tools convert it to JSON or XML when talking to an API or device.