YAML Formatter & Validator

YAML is the dominant configuration language for modern DevOps tooling — Kubernetes, GitHub Actions, Docker Compose, Ansible, Helm, GitLab CI, OpenAPI. Reading a 200-line manifest with broken indentation is the exact moment you need a tool like this.

How parsing works

The input is parsed by js-yaml’s loadAll (multi-document aware) into a JavaScript value tree. Format re-emits with dump; To JSON serialises with JSON.stringify. Validate parses and summarises without re-emitting. js-yaml uses YAML 1.2 with the JSON_SCHEMA, which restricts type coercion to the safe subset (strings, numbers, booleans, null, arrays, objects).

The parser is dynamic-imported on first interaction, so the initial page load is fast even though js-yaml itself is ~25 KB. The first format or validate carries a ~50ms delay; everything after that is instant.

Example: cleaning up a docker-compose file

Input (broken indentation):

version: '3'
services:
   web:
    image: nginx
    ports:
        - "80:80"
   db:
    image: postgres

Format:

version: '3'
services:
  web:
    image: nginx
    ports:
      - 80:80
  db:
    image: postgres

Consistent 2-space indent, normalised quote-stripping for unambiguous values.

Example: validating a Kubernetes manifest

Paste the manifest, hit Validate. A clean parse produces Valid YAML — 1 document (or N documents for multi-resource files). A bad indent inside a metadata.labels block produces an error like bad indentation of a mapping entry at line 8, column 5 — points you straight at the problem.

Example: converting to JSON

Some tools (jq, Stripe CLI, anything that consumes JSON natively) need JSON, not YAML. Paste the YAML, switch to To JSON mode, copy. A two-line config like:

service: api
port: 8080

becomes:

{
  "service": "api",
  "port": 8080
}

Round-tripping is lossless for any structure that uses only JSON-compatible types — most YAML in the wild qualifies.

Common YAML mistakes

Mixed tabs and spaces. YAML mandates spaces. A single tab anywhere in the file produces a hard parse error in most parsers (and worse, sometimes a silent type confusion). The validator here will reject mixed indentation.

Unquoted boolean-shaped strings. Country code NO, version Yes, postal code Off — under YAML 1.1 these parse as booleans. The JSON_SCHEMA used here treats them as strings, but if you’re consuming the output with a different YAML library, quote them defensively: code: 'NO'.

Tabs in inline arrays. [a,\tb] (where \t is a tab) is malformed. Use spaces inside flow-style structures.

Multi-line strings without folded / literal indicators. A bare multi-line value adjacent to a : is interpreted differently from > (folded) or | (literal). If your value contains newlines or trailing whitespace that matters, use the explicit indicator.

What this tool does not do

It doesn’t preserve comments. js-yaml drops them on parse. For round-tripping with comments intact, use ruamel.yaml or another comment-preserving parser.

It doesn’t support YAML 1.1 type coercions (Yes/No/On/Off as booleans). JSON_SCHEMA is the safer default for modern config.

It doesn’t validate against a schema. For schema validation (JSON Schema, OpenAPI, Kubernetes API), use a dedicated validator with the schema loaded.

It doesn’t resolve anchors and aliases across documents. Within a single document, anchors (&name) and aliases (*name) work; cross-document references aren’t a YAML feature anyway. To translate to or from JSON while keeping the formatting discipline, the YAML ↔ JSON converter is the companion.