One stray space at the wrong indent level turns a Kubernetes Deployment into something the API server cannot parse. The error message — found character '\t' or mapping values are not allowed here — points at the symptom, not the cause. This formatter re-parses your YAML with js-yaml and emits it back with one consistent indent, normalized quoting, and the option to sort keys for diff-friendly output. Works on Kubernetes manifests, Docker Compose, GitHub Actions, CircleCI / GitLab pipelines, and any YAML 1.2 document. Nothing leaves your browser.
How to format YAML
- Paste YAML — configs, manifests, or compose files into the left editor.
- Pick indent width. 2 spaces is the default for Kubernetes and Compose; 4 spaces shows up in some Python-adjacent stacks.
- Sort keys (optional) to alphabetize every level — handy for keeping CI diffs small.
- Format for a clean block style, or Minify for a compact single-document output.
- Copy or download straight into your repo.
Example 1: Fix mixed indentation in a Compose file
Copy-pasted Compose fragments usually carry inconsistent indentation from whatever source they came from. The formatter rewrites the whole file at a uniform 2-space indent.
Input
services:
web:
image: nginx:1.25
ports:
- "80:80"
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: secretOutput
services:
web:
image: nginx:1.25
ports:
- "80:80"
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: secretExample 2: Flow style to block style
Inline JSON-like YAML is valid but hard to diff. Block style spreads keys and list items onto their own lines so PR reviews stay readable.
Input
job: { name: build, steps: [checkout, install, test], timeout: 600 }Output
job:
name: build
steps:
- checkout
- install
- test
timeout: 600YAML specification reference
Quick reference from YAML 1.2. The converter enforces these rules on input; anything outside them is rejected or normalized.
| Element | Meaning | Example |
|---|
| Mapping | Block or flow key/value pairs | name: alice |
| Sequence | Ordered list with `- ` or flow `[...]` | - apple
- banana |
| Scalar | Plain, single-quoted, double-quoted, literal `|`, folded `>` | "hello\n" |
| Anchor / alias | & defines, * references; enables DRY configs | &base
*base |
| Tag | Explicit type: !!int, !!str, !!binary … | !!int "42" |
Common invalid forms
name:alice // missing space after colon
- item
-indented // inconsistent indent
flag: yes
value: 1 // tab used for indent (YAML forbids tabs)
Indentation: tabs vs spaces
The YAML 1.2 spec is explicit: tab characters cannot be used for indentation. Most editors hide this — they show tabs and spaces identically. Symptoms include parsers rejecting the file with found character '\t', or worse, partial parsing where one branch of the document loads and another silently drops. The formatter replaces every tab with the configured number of spaces during the round-trip.
- VS Code fix: add
"[yaml]": { "editor.insertSpaces": true, "editor.tabSize": 2 } to settings.json. - EditorConfig:
[*.{yaml,yml}] indent_style = space / indent_size = 2. - Pre-commit hook:
yamllint -d "{rules: {indentation: {spaces: 2}}}".
Common YAML pitfalls this formatter exposes
- Norway problem. Unquoted
NO, YES, ON, OFF can parse as booleans (YAML 1.1 behavior). With YAML 1.2 they stay strings, but pasting into a YAML 1.1 consumer changes the semantics. Quote ambiguous values: countryCode: "NO". - Octal numbers. A leading zero like
022 may be parsed as octal (decimal 18) under YAML 1.1, or as a string under YAML 1.2. Always quote file mode and permission values. - Anchor expansion. The formatter resolves anchors and aliases inline. If you depend on the DRY structure, do not run formatting on the source-of-truth file.
- Comments lost. js-yaml does not preserve comments through the parse-and-emit cycle. Use a comment-preserving YAML LSP in your editor for files where comments matter.
- Bare numeric strings. Phone numbers, ZIP codes, and Docker image tags like
1.10 lose trailing zeros once parsed as numbers. Always quote identifiers that look numeric.
This formatter vs yamlfmt and prettier
| Tool | Preserves comments? | Sort keys? |
|---|
| This formatter (js-yaml) | No | Optional |
yamlfmt | Yes | Optional |
prettier --parser yaml | Yes | No |
yq eval -P | Partial | Via expression |
When comments matter (Helm values with inline docs, Compose files with feature flags), use yamlfmt or prettier in CI. Use this tool for quick paste-and-format on files where the comments are throwaway.
Common use cases
- Normalize Kubernetes manifests before committing to Git
- Clean up docker-compose.yml after hand editing
- Sort GitHub Actions workflow keys for consistent review
- Prepare Ansible playbooks and Helm values files
- Beautify CircleCI / GitLab CI configurations
Related guides
JSON vs YAML: When to Use What — A Developer's Guide
JSON wins on APIs; YAML wins on configs. Side-by-side syntax, parser behaviour, and where each fits across Kubernetes manifests, REST payloads, and GitHub Actions.
Docker Compose for Beginners: From docker run to YAML
How to translate a pile of docker run commands into a single docker-compose.yml. Service definitions, named networks, volumes, env files, and the override patterns for dev vs prod.
YAML Configuration Files: Syntax, Best Practices, and Common Pitfalls
YAML whitespace is unforgiving and the Norway problem (no:) still bites. Types, anchors, aliases, and the rules that keep Kubernetes manifests, GitHub Actions, and Helm values readable.
Kubernetes Manifest Validation: Catch Errors Before kubectl Apply
The cluster is the most expensive place to discover a YAML typo. Schema validation, server-side dry-run, CRDs, and the apiVersion graveyard.
Frequently Asked Questions
Q: Why are my comments gone after formatting?
js-yaml — the library this tool uses — parses semantic content only and discards comments. The parse-and-re-emit cycle cannot recover them. For comment-preserving formatting, use yamlfmt or prettier --parser yaml as a local CLI. When the comments are critical, format in your editor with a YAML LSP instead of running through this tool.
Q: Does sorting keys break a YAML consumer?
YAML maps are unordered by spec, so any compliant parser ignores key order. However, some tools rely on visual conventions (Kubernetes manifests tend to start with apiVersion and kind). Sorting alphabetically is safe for correctness but may make manifests harder to read. Use it for files where deterministic diff matters more than reading order.
Q: Which YAML version is supported?
YAML 1.2 through js-yaml. This is the default for almost every modern toolchain including Kubernetes, Helm, Docker Compose v2/v3, GitHub Actions, and most CI systems. The Norway problem (NO as boolean) only affects YAML 1.1, which is rare in 2026.
Q: What does the Minify button do?
It re-emits the document in flow style — JSON-like inline form — which keeps the data valid but as compact as possible. Useful when you need to embed YAML inside a shell script, environment variable, or HTTP request body where newlines complicate quoting. For most repo files you want the formatted (block) version instead.
Q: Will the formatter fix a Norway problem in my file?
The formatter preserves the values you wrote. If you typed code: NO without quotes, it stays that way in the output. To force string quoting, edit the source to code: "NO" before formatting. The YAML Validator will flag these ambiguous values if you want a separate audit.