YAML Formatter

YAML ("YAML Ain't Markup Language") is the configuration format that ate the world of DevOps. Kubernetes manifests, GitHub Actions workflows, Ansible playbooks, Docker Compose files, OpenAPI specs, CircleCI configs, and a thousand application YAML config files all use it. The appeal is that it reads like plain text: significant indentation instead of braces, no required quotes around string keys, comments. The pain is that this same flexibility makes YAML the most subtly-tricky-to-parse configuration format in common use. Strings that look like numbers parse as numbers. Strings that look like booleans parse as booleans. Indentation matters, and a single misplaced space changes meaning.

This tool wraps **`js-yaml`** — the JavaScript reference implementation of the YAML 1.2 spec, and the same parser GitHub Actions uses internally to read workflow files. The Format action runs your YAML through `load` → `dump`, which produces the canonical representation that downstream consumers like Kubernetes would also see. That round-trip surfaces a class of bugs immediately: if your original input parses to one thing and the canonical output looks different, you know your spelling was wrong even if it "worked."

The most famous YAML hazard is the **Norway problem**. The country code for Norway is `NO`. YAML 1.1 (the older spec) treats `NO` (case-insensitive) as a boolean false. So this config:

```yaml countries: - NO - SE - DK ```

parsed as `[false, "SE", "DK"]` in YAML 1.1. YAML 1.2 narrowed the boolean set to just `true` and `false`, and `js-yaml` defaults to 1.2, so this specific bug is gone — but the type-coercion table still has `yes`/`no`/`on`/`off` mapping to booleans in older code, and unquoted numbers (`version: 3.10` becomes `3.1`, not `"3.10"`) is still a regular source of bugs. The fix is always the same: quote anything that might be ambiguous.

The **YAML → JSON** conversion is one of the most-used features of any YAML tool. JSON is more constrained — no multi-line strings, no comments, fewer type coercions — which is exactly why application code often prefers it. Convert YAML to JSON and you get a normalized version your downstream code can handle without ambiguity. The reverse direction (JSON → YAML) produces idiomatic YAML output, which is useful when you have programmatic data and want to write a config file a human will edit.

Two things this tool deliberately does not do. **Anchors and aliases** (`&name` / `*name`) get inlined on output with `noRefs: true`. YAML lets you define a value once and reference it elsewhere, but `js-yaml` does not preserve those references through a round-trip — if you need anchor preservation, you need a "round-tripping" parser like Python's `ruamel.yaml`. **Multi-line string spelling** also gets normalized. YAML has `|` (literal blocks, preserving newlines), `>` (folded blocks, joining lines with spaces), and quoted-with-escapes; the dumper picks the form that best fits each string's content rather than preserving your original choice. The semantic content is identical; only the representation changes.

A practical note: **2-space indentation is the only sane default for YAML.** Kubernetes uses 2. GitHub Actions uses 2. Ansible uses 2. OpenAPI uses 2. The tool defaults to 2 because deviating from this in a real project's YAML invariably leads to mixed-indent files that some tools accept and others reject. The 4-space and 6-space options exist for the small set of legacy projects that have committed to those.

Everything runs in your browser. The `js-yaml` library is ~50 KB compressed and is bundled with the tool's chunk. No network requests, no logging. Pasting a Kubernetes manifest with internal hostnames or an Ansible playbook with environment-specific values is safe — nothing leaves your tab.