YAML Formatter
Format YAML with a consistent indent width, or convert it to JSON. Detects tab characters and inconsistent indentation.
Tips
- This tool uses a lightweight custom-built parser, supporting key: value pairs, nesting, lists, and inline
[a, b, c]/{a: 1}syntax. - Even if you paste YAML with inconsistent indentation (3 or 5 spaces, for example), it will be re-output with a uniform 2- or 4-space indent as long as it parses successfully.
- In "Convert to JSON" mode, you can preview your YAML converted straight to JSON — handy for comparing against CI configs or API responses.
- If you get an error, the line number is shown, so check that line for indentation problems or a missing space after the colon.
- YAML forbids tab-based indentation. Enabling "convert tabs to spaces" in your editor settings can help you avoid this pitfall entirely.
Frequently Asked Questions
|/>).no, yes, on, or off without quotes gets interpreted as a boolean by many YAML implementations instead of a plain string (such as Norway's country code). If you want it treated as a string, wrap it in quotes, e.g. "no".
Side Note — Why YAML Became the Go-To Config Format
YAML (YAML Ain't Markup Language) is a data serialization format that appeared in 2001. Since it requires no closing tags and looks much simpler than XML, it has become the standard choice for infrastructure config files since the 2010s — Docker Compose, GitHub Actions, and Kubernetes manifests all use it.
That said, YAML's design of "structure through indentation" is easy for humans to read, but also fragile: indentation breaks easily when copy-pasting. In particular, mixing tabs and spaces can cause many parsers to silently produce the wrong structure without raising an error, which makes it a common source of unintended configuration mistakes.
There's also a well-known pitfall called the "Norway Problem." Writing the country code no without quotes gets interpreted as the boolean false by many YAML implementations. Differences in which strings count as booleans between YAML 1.1 and 1.2 are also a frequent source of cross-implementation compatibility issues.