What YAML is and why it was designed
YAML (YAML Ain't Markup Language, a recursive acronym) is a human-readable data serialization format designed to be writable by hand without angle brackets, braces, or comma-delimited syntax. Keys and values are separated by a colon and a space; structure is expressed by indentation alone. YAML is a strict superset of JSON, every valid JSON document is also valid YAML, but YAML allows comments, unquoted strings, and multi-line text blocks that JSON cannot express.
YAML has become the configuration language of the DevOps toolchain. Docker Compose, Kubernetes manifests, GitHub Actions workflows, GitLab CI pipelines, Ansible playbooks, Helm charts, and AWS CloudFormation (in its YAML mode) all use it. The appeal is legibility: a Kubernetes deployment file read top-to-bottom tells a reader what container image to run, what environment variables it needs, and how many replicas to keep alive, without parsing syntax noise.
YAML data types and syntax rules
Scalars: plain values, are inferred by context. true, false, yes, and no are booleans. Bare digits are numbers. Everything else is a string. Quote a value with single or double quotes to force it to be treated as a string: "true" is the string true, not the boolean. Lists use a leading dash and space (- item). Maps use key: value pairs. Nesting is expressed by consistent indentation, always spaces, never tabs (the YAML spec bans tabs to avoid display-width ambiguity between editors).
Multi-line strings use two operators. The literal block scalar | preserves newlines, useful for shell scripts and SQL embedded in config. The folded block scalar > replaces newlines with spaces, useful for long human-readable descriptions that wrap in the source file but should be a single string at runtime.
| Syntax | Example | Result type |
|---|---|---|
| Plain string | name: Alice | String "Alice" |
| Quoted string | flag: "true" | String "true" (not boolean) |
| Boolean | enabled: true | Boolean true |
| Integer | port: 8080 | Integer 8080 |
| Float | ratio: 0.75 | Float 0.75 |
| Null | debug: ~ or debug: | Null value |
| List | - item1- item2 | Array ["item1","item2"] |
| Literal block | script: | echo hello | String "echo hello\n" |
Anchors, aliases, and reducing repetition
YAML anchors (&name) and aliases (*name) let you define a value once and reference it multiple times. In a GitHub Actions workflow you might define a common set of environment variables as an anchor and reuse them across five jobs. In a Kubernetes config you might anchor the resource requests for a standard container and apply them to every deployment. This keeps large config files DRY (Don't Repeat Yourself) without templating engines. Anchors are resolved at parse time, so the output seen by the application has the values fully substituted.
Common YAML errors and how to find them
The most frequent YAML parsing failure is inconsistent indentation: mixing tab characters with spaces, or using different indentation depths for sibling keys. Paste the failing config here and click Format: if the formatter reports a parse error, the line number identifies the indentation conflict. Other common errors include: a bare colon in a string value that must be quoted (message: "Error: timeout"), a boolean keyword where a string is expected (password: "no" not password: no), and duplicate keys in the same mapping (allowed by spec but usually a bug).
Related tools: JSON formatter (YAML is a superset of JSON), XML formatter for SOAP and enterprise data feeds. See the CI/CD developer guide for linting YAML manifests in GitHub Actions and GitLab pipelines.