Free YAML Formatter & Validator

What Is YAML?

YAML (YAML Ain't Markup Language) is a human-readable data serialization format used for configuration files (Docker, Kubernetes, GitHub Actions, Ansible), data exchange, and more. It uses indentation instead of braces and is a superset of JSON.

Frequently Asked Questions

What errors does the validator catch?

Indentation errors, missing colons, duplicate keys, invalid characters, unclosed strings, bad nesting, and other YAML syntax issues. Error messages include line numbers.

Can I convert YAML to JSON?

Yes! Click the "→ JSON" button to convert your YAML to nicely formatted JSON. For the reverse, use our JSON to YAML Converter.

A Quick Tour of YAML

YAML 1.0 was published in 2001 by Clark Evans, Ingy döt Net, and Oren Ben-Kiki; YAML 1.1 followed in 2005, and the current version is YAML 1.2.2, which fixed several historical gotchas (notably the "Norway problem", see below) and was designed to be a strict superset of JSON. The official spec lives at yaml.org/spec/1.2.2. This formatter uses the open-source js-yaml library, which parses against the YAML 1.2 schema by default, so most of the legacy 1.1 quirks don't apply to text formatted here, but they do apply to most server-side YAML tooling you'll send the output to.

Where YAML Actually Lives

YAML has won as the configuration format for cloud-native infrastructure. The places you'll meet it most:

• Kubernetes manifests: every Pod, Deployment, Service, ConfigMap, Ingress is a YAML document. Helm charts are YAML wrapped around Go templating.
• CI/CD workflows: GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines, Drone, Jenkinsfile (declarative pipelines), Argo Workflows.
• Docker Compose: multi-container application definitions.
• Ansible playbooks: the configuration-management standard.
• Static-site generators: Jekyll's _config.yml, Hugo's config.yaml, Eleventy's various config files.
• OpenAPI specifications: REST API contracts, often authored as YAML and converted to JSON only when needed.
• Application config: Spring Boot's application.yml, Rails' database configs, many Python and Go services.

The Whitespace Trap (Spaces Only)

YAML uses indentation to denote structure, and the spec is explicit that tabs are not allowed for indentation. Only spaces. This is the single most common source of bugs in handwritten YAML, especially because many editors silently mix tabs and spaces depending on their settings. The error message you'll get from a strict parser is along the lines of "found character '\t' that cannot start any token", translation: "you used a tab somewhere." The fix is universal: enable "show whitespace" in your editor and convert every tab to two or four spaces.

Indent size is convention rather than spec. 2 spaces is the de facto standard for Kubernetes manifests, GitHub Actions, and most YAML you'll read on the modern web. 4 spaces is more common in Ansible. The rule that matters: be consistent within a single file. Mixing 2 and 4 spaces between sibling keys is what trips parsers, not which size you pick.

The Norway Problem (and Why You Should Quote Ambiguous Strings)

YAML 1.1 (still the default in PyYAML, snakeyaml, and many other server-side parsers) interprets a long list of unquoted boolean spellings as actual booleans: true, True, TRUE, false, False, FALSE, yes, Yes, YES, no, No, NO, y, n, on, off. The famous trap: the ISO country code for Norway is NO. A YAML config that lists countries as unquoted strings silently parses Norway as the boolean false, and downstream code reading countries[0] == 'NO' fails confusingly.

YAML 1.2 (and js-yaml's default schema) restricted booleans to just true / false, which fixes the Norway problem at the parser level. But many real-world tools still default to the YAML 1.1 schema for backward compatibility. The defensive habit: quote any string that looks like it could be a boolean, number, date, or version. country: "NO", postal_code: "01234", version: "1.10", time: "10:30". Quotes are the universal disambiguator.

Other Type-Coercion Gotchas

• Sexagesimal numbers (YAML 1.1). An unquoted 10:30 parses as the integer 630 (ten times sixty plus thirty). Anything that looks like a time-of-day needs quotes.
• Octal numbers. An unquoted 012 parses as the integer 10 in YAML 1.1 (octal interpretation of leading-zero numbers). US zip codes, employee IDs, postal codes that begin with zero must be quoted: zip: "01234".
• Version-number floats. An unquoted 1.10 parses as the float 1.1. Always quote semver strings: version: "1.10".
• Scientific notation. 1e5 parses as the number 100000. If you genuinely meant the string "1e5" (a product code, an internal ID), quote it.
• Very large integers. JavaScript-based YAML parsers (including js-yaml) can lose precision on integers above 2⁵³−1. For 64-bit IDs, transmit as strings.

Block Style vs Flow Style

YAML supports two notations for the same data:

# Block style (the standard, indentation-based)
person:
  name: Alice
  tags:
    - admin
    - billing

# Flow style (JSON-like inline)
person: { name: Alice, tags: [admin, billing] }

Block style is what you'll see in 99% of hand-written YAML, it's what makes the format readable. Flow style is a useful escape hatch for short single-line values or for programmatically generating YAML where you'd rather not track indentation. The formatter normalises to block style for output (the more readable form) regardless of which style your input used.

Anchors and Aliases (the DRY Trick)

YAML's reusability feature: define a value once with the &name anchor, reference it elsewhere with the *name alias. Convenient for long config files where the same block of values appears multiple times.

defaults: &defaults
  region: us-east-1
  log_level: info

production:
  <<: *defaults
  log_level: warn   # override

staging:
  <<: *defaults

A few caveats: not every YAML processor supports anchors and aliases (notably some older Kubernetes manifest tools and certain Helm contexts). The <<: "merge key" syntax shown above is a YAML 1.1 extension and is officially deprecated in 1.2, js-yaml supports it, but pure 1.2 parsers may not.

Multi-Document Files

A single YAML file can contain multiple documents, separated by ---. Common in Kubernetes, one file with a Deployment, a Service, and a ConfigMap, separated by ---, applied with one kubectl apply -f:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
---
apiVersion: v1
kind: Service
metadata:
  name: app-svc

YAML vs JSON vs TOML

• JSON: machine-friendly, no comments allowed, bracketed. Universal API payload format.
• YAML: human-friendly, comments allowed, indentation-based, error-prone for humans. Universal config format for cloud-native tooling.
• TOML: human-friendly, comments allowed, INI-style, far less error-prone than YAML for flat configuration. Cargo (Rust), Hugo, Black (Python), Poetry, modern Pip, all use TOML.

If you have a choice for new config: TOML for flat configuration, YAML if you need deep nesting and the ecosystem has standardised on it (Kubernetes, Ansible), JSON if a machine writes it. YAML is the right format when humans need to read deeply nested config and write meaningful comments inline.

Privacy

YAML configs frequently contain secrets that shouldn't go through someone else's server: Kubernetes Secret base64 blobs, database passwords in application.yml, API keys in CI workflows, internal hostnames in deployment configs. The formatter runs entirely in your browser via the open-source js-yaml library, pasted content is parsed and re-emitted locally, with no fetch / no upload / no logging. Closing the tab wipes everything.

Common Mistakes

1. Mixing tabs and spaces in indentation. The most common error. Tabs are forbidden by the spec; some editors insert them silently. Show whitespace in your editor.
2. Inconsistent indentation between siblings. Sibling keys must be aligned at the same column. Mixed 2/4-space indentation breaks the parse.
3. Unquoted values that look like booleans, numbers, dates, or times. NO, 012, 1.10, 10:30, yes: quote them.
4. Missing space after the colon. key: value works; key:value is invalid (parsed as a single string).
5. Trailing whitespace. Some parsers treat trailing spaces as significant; some don't. The cross-tool-safe habit is to strip trailing whitespace.
6. Multi-line strings without the right block scalar. Long strings need | (literal, preserves newlines) or > (folded, joins lines). Plain unquoted multi-line text rarely behaves the way you expect.
7. Anchors / aliases assumed everywhere. Helm and some Kubernetes contexts don't fully support &/*. Test in your real pipeline before depending on them.
8. Encoding mismatches. YAML files should be UTF-8. A Windows editor saving as UTF-16 with BOM produces files that some parsers can't read.

More Frequently Asked Questions

Will the formatter preserve my comments?

No. The js-yaml library parses YAML into a JavaScript value and re-emits it from that value, which means comments (# like this) are dropped, they live in the source text, not in the parsed structure. If preserving comments matters (it usually does for hand-curated config files), use a comment-preserving alternative like eemeli/yaml via its CST API, or do small edits by hand rather than round-tripping through this formatter.

Why does my NO get treated as a boolean by my server's YAML parser?

Because that parser is using YAML 1.1 (the default for PyYAML, snakeyaml, and many others), which interprets NO as the boolean false. This formatter uses YAML 1.2 by default (via js-yaml) so it doesn't trigger the bug here, but the moment you ship the file to a YAML 1.1 environment the trap activates. Always quote ambiguous strings: country: "NO".

Can I convert YAML to JSON?

Yes, click "→ JSON". The conversion is lossless for everything that can be represented in JSON (strings, numbers, booleans, null, arrays, objects). Things that don't survive: comments (JSON has no syntax for them), anchors and aliases (JSON has no equivalent), and YAML's date / time-stamp types (which become strings in JSON). For the reverse direction, use the dedicated JSON to YAML tool.

Is anything sent to a server?

No. All parsing, formatting, and JSON conversion run in your browser via js-yaml. The pasted YAML is never transmitted to any server. This matters because YAML configs frequently contain secrets (Kubernetes Secret values, database passwords, API keys, internal endpoints) that shouldn't be uploaded to a third-party service.

What's the size limit?

No hard limit, the formatter runs in your browser's memory. Typical Kubernetes manifests (a few KB) and Helm charts (tens of KB) format instantly. Very large multi-document files (multiple MB) can be slow but generally work; if you have a 10-MB Helm chart, format it locally with a CLI tool instead.

Why is YAML so error-prone?

Three reasons that compound: (1) significant whitespace means typos cause silent semantic changes; (2) YAML 1.1's permissive type coercion turns ambiguous strings into unintended booleans / numbers; (3) the format has too many ways to write the same thing (block vs flow, single vs double quotes, three flavours of multi-line strings. The defensive habits) always quote, always be consistent with indentation, validate before deploying, fix most of the surface area.

Related Tools