Format and validate YAML files instantly — check for indentation errors, validate structure and produce cleanly formatted YAML for configs and CI/CD pipelines.
Enter your figures and click Calculate to see your results.
Paste your YAML content and select validate or format — the tool checks indentation, structure and reports any issues found.
Click the Format button. Your code is processed instantly — all formatting runs in your browser with no data sent to servers.
The formatted output appears on the right. Click Copy to grab it, or Download to save as a file. Statistics like size reduction and line count are shown automatically.
YAML (YAML Ain't Markup Language) is a human-readable data serialisation format. It is widely used for configuration files: GitHub Actions, GitLab CI, Kubernetes manifests, Docker Compose, Ansible playbooks, Travis CI, CircleCI, Jekyll static sites, and many application config files. YAML's indentation-based structure makes it more readable than JSON or XML for configuration, but also more fragile — indentation errors are the most common issue.
YAML errors most commonly involve: incorrect indentation (tabs are not allowed — only spaces; mixing indent levels causes parse errors), missing quotes around special characters (: { } [ ] , & * # ? | - < > = ! % @ \ must be quoted in some contexts), duplicate keys (technically allowed but produces unpredictable results), incorrect list formatting (each - must be indented consistently), and multiline string issues (| for literal blocks, > for folded blocks).
YAML is a superset of JSON — valid JSON is valid YAML. YAML adds: comments (# comment), multiline strings, anchors and aliases (for reuse and DRY), multiple documents in one file (--- separator), implicit typing (true/false/null without quotes), and human-friendly syntax without braces and quotes. YAML's flexibility makes it ideal for config files; JSON's strictness makes it better for data exchange and API responses.
YAML anchors (&name) define a reusable block; aliases (*name) reference it. Example: defaults: &defaults\n env: production\n debug: false\nservice1:\n <<: *defaults\n port: 3000. The merge key (<<) merges all keys from the anchor into the current mapping. Anchors are powerful for DRY configuration — changing the anchor updates all references. They are heavily used in Docker Compose and GitLab CI configurations.
YAML has two block scalar styles: Literal block (|) preserves newlines exactly — useful for scripts and text where line breaks matter. Folded block (>) folds newlines into spaces (like word wrap) — useful for long descriptions. Both support block chomping: | (clip — keep final newline), |- (strip — remove all trailing newlines), |+ (keep — preserve all trailing newlines). Flow scalars ("quoted" and unquoted) have their own line-folding rules.
Kubernetes manifests are YAML files that define the desired state of cluster resources. Each manifest has: apiVersion, kind (Pod, Deployment, Service, etc.), metadata (name, namespace, labels) and spec (the desired configuration). kubectl apply -f manifest.yaml sends the YAML to the Kubernetes API server, which reconciles the cluster state to match. GitOps (ArgoCD, Flux) manages Kubernetes by storing YAML manifests in Git and syncing automatically.
Block style uses indentation and newlines (the typical YAML format most people recognise). Flow style uses JSON-like syntax with braces and brackets: {key: value} for mappings, [item1, item2] for sequences. Flow style can appear inline within block-style YAML. Formatters generally convert flow style to block style for readability, though flow style is sometimes preferred for short, simple values.
Common YAML validation tools: yamllint (Python CLI — checks syntax and style), GitHub Actions has built-in workflow validation, kubeval/kubeconform validate Kubernetes manifests against schemas, cfn-lint validates AWS CloudFormation templates, ansible-lint validates Ansible playbooks. Many editors (VS Code with YAML extension, JetBrains IDEs) validate YAML in real time using JSON Schema definitions, catching errors before commit.
