YAML is a human-oriented serialisation language designed primarily to represent structured data in a syntax intended to be easier to read and write than many traditional machine-oriented formats. The name is commonly expanded as "YAML Ain't Markup Language", reflecting its identity as a data serialisation language rather than a document markup system. YAML uses indentation and significant whitespace to represent hierarchical structure, while mappings, sequences and scalar values provide fundamental data structures.
It can express strings, numbers, booleans, null values and more elaborate constructs depending on the YAML version and implementation. YAML is widely encountered in configuration files, deployment definitions, automation systems and infrastructure tooling, although its exact supported features and behaviour can vary significantly between parsers.
YAML was created by Clark Evans, Ingy döt Net and Oren Ben-Kiki and first appeared in the early 2000s. Its design drew inspiration from ideas found in languages and formats including XML, C, Perl, Python and JSON, while placing particular emphasis on human readability. YAML 1.1 became influential in configuration and automation ecosystems, while YAML 1.2 revised the specification to improve compatibility with JSON's data model and clarify some language interpretation issues. The ecosystem nevertheless contains implementations with differing levels of YAML-version support, making parser behaviour an important practical consideration.
YAML represents mappings through key-value relationships and sequences through ordered lists, with indentation determining hierarchy. A sequence can be represented with hyphen-prefixed entries, while mappings generally use a colon between keys and values. Scalars can be written in plain, quoted or block forms. Single-quoted and double-quoted strings have different escaping rules, while literal and folded block scalars allow multiline text to be represented in ways useful for configuration and documentation. YAML permits comments beginning with a hash character, which is one reason it is attractive for configuration files. Unlike JSON, YAML allows several stylistic choices that can make the same logical data appear in substantially different textual forms.
YAML supports features beyond JSON's basic object-array-value model, including anchors, aliases, tags and complex keys. Anchors allow a node to be given a reusable identifier, while aliases can refer back to previously defined nodes. These capabilities can reduce duplication but can also make documents harder to understand and introduce implementation complexity. Tags can communicate type information, although support and security implications depend on the parser. YAML can therefore express richer structures than straightforward JSON-compatible data, but this additional expressive power is also a source of confusion and portability problems. Configuration authors should understand which subset their consuming application actually supports rather than assuming every YAML feature is universally available.
YAML's indentation sensitivity is one of its defining characteristics and one of its most common sources of errors. Indentation determines nesting, so changing whitespace can change the meaning of a document. Tabs and spaces are not interchangeable in YAML indentation, and inconsistent indentation can produce parsing failures or unintended structures. Quoting can also affect interpretation, particularly for values resembling booleans, numbers, dates or other special scalar forms. YAML 1.1 and YAML 1.2 differ in how certain unquoted values are interpreted, meaning a configuration that appears visually obvious to a human may be parsed differently by different libraries.
YAML is heavily used in software configuration and automation. CI/CD systems, infrastructure-as-code tools, container orchestration systems and application configuration frameworks frequently expose YAML-based interfaces. Kubernetes manifests are a prominent example, although Kubernetes itself accepts YAML representations that are ultimately converted into structured API objects and does not simply treat arbitrary YAML as application logic. GitHub Actions workflow files also commonly use YAML syntax. In these contexts, YAML's role is generally declarative: a document describes desired configuration or workflow structure that another system parses and acts upon. The meaning of a particular key is therefore determined by the consuming application, not by YAML itself.
YAML is closely related to JSON because YAML 1.2 was designed with JSON compatibility in mind, and valid JSON can generally be treated as YAML under appropriate YAML processing rules. However, YAML is not merely "JSON with indentation": it has additional syntax and semantic features, multiple scalar styles and mechanisms such as anchors and tags.
YAML also differs from XML, which uses explicit markup tags and has a formal namespace ecosystem, and from Markdown, which is primarily lightweight document-authoring syntax rather than a general data serialisation system. A common misconception is that YAML is inherently safer than JSON because it is human-readable. Parser behaviour matters more than visual readability, and historically unsafe YAML deserialisation features have caused security vulnerabilities in applications.
YAML's advantages include readability, comments, multiline text support, concise representation of nested configuration and extensive use in modern automation ecosystems. Its disadvantages include whitespace sensitivity, parser differences, surprising implicit typing, complex syntax edge cases and potential security issues with advanced object-construction mechanisms. Safe YAML processing should use parsers configured for data-only interpretation when untrusted input is possible, validate the resulting structure and avoid assuming that syntactic correctness guarantees acceptable configuration. YAML is best understood as a flexible serialisation language whose practical meaning depends strongly on its specification version, parser implementation and consuming application.
