YAML Formatter

Most YAML errors come from whitespace. The validator stops at the first problem and shows its line and column; these are the usual causes.

The formatter uses Prettier's YAML printer. It re-indents nested maps and lists to the chosen width, normalises spacing around colons and dashes, tidies inline lists and maps, and uses consistent quotes. Comments, the order of keys, anchors and aliases, and multi-line block strings are kept. The data itself does not change, so the formatted file loads into exactly the same values as the original.

YAML is a superset of JSON for most practical purposes, so any YAML data can be written as JSON. Click YAML → JSON to see exactly what a program will read from your file: this is a quick way to check that a value you meant as text is not read as a number or a boolean. This tool follows YAML 1.2, where only true and false are booleans; older YAML 1.1 parsers (used by some tools) also read yes, no, on and off as booleans. Values such as 1.10 and 0123 are read as the numbers 1.1 and 123, so put them in quotes if they should stay text. JSON → YAML does the reverse and is handy for writing config files from API output. Comments cannot be represented in JSON, so they are dropped when converting.

A YAML file can hold several documents separated by a line with three dashes. Kubernetes uses this to put a Deployment, a Service and a ConfigMap in one file. The validator checks every document and the status shows how many it found. When you convert to JSON, a single document becomes one object, and several documents become a JSON array with one item per document.

The formatter checks YAML syntax, which is the cause of most failed deployments and pipeline runs. It does not check the schema of a specific tool, such as whether a Kubernetes field name is spelled correctly or a GitHub Actions key exists. Validate syntax here first, then use the tool's own linter (for example kubectl with dry-run, or actionlint) for schema checks.