YAML Formatter

YAML is whitespace-sensitive, which makes it pleasant to read and unforgiving to edit. The tool above does three things: tidies YAML into a canonical shape, converts it to JSON, and converts JSON back to YAML — all in your browser, so a Kubernetes manifest or a CI file with secrets in it never leaves your machine.

How it works

Pick a mode, paste your document, and choose a 2- or 4-space indent.

• Format YAML parses the document and re-serialises it. This normalises indentation, quoting and list style, and collapses the various ways of writing the same value into one.
• YAML → JSON parses the YAML and emits JSON at your chosen indent. Useful for feeding a config file to something that only speaks JSON, and for seeing exactly what a parser thinks your YAML means.
• JSON → YAML does the reverse, which is the quickest way to make a generated JSON blob reviewable in a pull request.

Parsing uses a spec-compliant YAML 1.2 parser, so errors come back as real parser messages with a line and column rather than a generic "invalid input". That error text is often the most useful output the tool produces.

Note that formatting is a round trip through the data model, not a text transformation. That has one consequence worth knowing up front: comments are dropped. If your file's comments matter — and in a Kubernetes or CI file they usually do — use the format mode to check the structure, then apply fixes to your original by hand.

Why YAML bites

Indentation must be spaces. Tabs are illegal in YAML indentation, full stop. An editor configured to insert tabs produces a file that fails to parse with an error that points at the wrong place.

The Norway problem. YAML 1.1 treated yes, no, on, off, y and n as booleans, so a country list containing NO parsed as false. YAML 1.2 removed this, but many deployed parsers still implement 1.1 behaviour. Quote ambiguous scalars: "NO", "on", "1.0".

Unquoted version numbers. 1.0 is a float, 1.10 is the float 1.1, and 1.0.0 is a string. Image tags and version pins should always be quoted.

Leading zeros. 08 may parse as an invalid octal in older parsers; "08" is safe. The same applies to anything that looks like a number but is an identifier — phone numbers, zip codes, account references.

Duplicate keys. The spec says they are invalid, but many parsers silently keep the last one. A long file with a repeated key is a defect that no error message will point at.

Running a file through YAML → JSON answers all of these at once, because JSON has no ambiguity: whatever appears as true or 1.1 in the JSON output is what your parser actually saw.

YAML or JSON?

They express the same data model, so the choice is about audience. YAML is for files humans write and review — its comments, block scalars and anchors exist for that. JSON is for machines: no comments, no ambiguity, one way to write each value, and a parser in every language. Every JSON document is valid YAML 1.2, which is why the conversion in this tool is lossless in that direction and only structurally lossless in the other.

Where it shows up

YAML is the configuration language of the container and CI world, and most of the time you meet it you are debugging an indentation problem in someone else's file. Docker Compose networking and volumes works through the structure of a Compose file, Kubernetes fundamentals covers manifests and the apply model, and Jenkins pipelines and the Jenkinsfile covers pipeline definitions. On the application side, starters, properties and profiles explains how application.yml is resolved and overridden.

For JSON on its own, the JSON formatter is the more direct tool; for markup, the HTML formatter.