7 Common YAML Errors (and How to Fix Them)
YAML's readability comes at a cost: whitespace sensitivity. A single misplaced space or tab can crash your Kubernetes deployment or CI pipeline. Here are the seven most common YAML errors developers face and exactly how to fix them.
1. Tabs Instead of Spaces
What happens: Your YAML parser throws "found character that cannot start any token."
Why: YAML only allows spaces for indentation. Tabs are forbidden. Many editors auto-insert tabs, and it's invisible to the eye.
# BROKEN (contains tab character)
deployment:
→name: my-app
→replicas: 3
# FIXED (spaces only)
deployment:
name: my-app
replicas: 3 Fix: Configure your editor to insert spaces when pressing Tab. In VS Code, add "editor.insertSpaces": true and "editor.tabSize": 2 to settings. Use our YAML formatter to auto-detect and fix tab issues.
2. Inconsistent Indentation Levels
What happens: "mapping values are not allowed in this context" or data ends up at the wrong nesting level.
Why: Mixing 2-space and 4-space indentation within the same file confuses the parser about nesting structure.
# BROKEN (mixed indentation)
server:
host: localhost
port: 8080 # 4-space indentation - port is now nested under host instead of server
# FIXED
server:
host: localhost
port: 8080 Fix: Pick one indent size (2 spaces is the YAML convention) and use it consistently throughout the file.
3. Missing Space After Colon
What happens: The entire key-value pair is treated as a single string rather than a mapping.
# BROKEN
name:John Doe
age:30
# FIXED
name: John Doe
age: 30 Fix: Always put a space after every colon that separates a key from its value. Most modern editors highlight this.
4. Accidental Boolean Conversion (Norway Problem)
What happens: Country codes like NO (Norway), YES, ON, or OFF get converted to booleans in YAML 1.1 parsers.
# DANGEROUS in YAML 1.1
country: NO # Parsed as boolean false instead of string "NO"
enabled: on # Parsed as boolean true
toggle: off # Parsed as boolean false
# SAFE
country: "NO"
enabled: "on"
toggle: "off" Fix: Always quote ambiguous strings, especially country codes, version strings, and yes/no values. Use true/false for booleans. Our formatter follows YAML 1.2 which resolves this ambiguity.
5. Broken Anchors and Aliases
What happens: "unknown alias" error or the alias doesn't resolve to the expected value.
# BROKEN - alias exists but anchor doesn't
config:
<<: *unknown_anchor
# BROKEN - anchor defined but never referenced correctly
defaults: &defaults
timeout: 30
service:
config: *defalts # Typo in alias name
# FIXED
defaults: &defaults
timeout: 30
service:
<<: *defaults 6. Multi-Document Separator Issues
What happens: Only the first document is processed when you meant to process all of them, or a bare --- at the top of the file is treated as a document separator.
# BROKEN - trailing content after document end marker
---
first: doc
...
second: doc # This is invalid; ... ends the stream
# FIXED
---
first: doc
---
second: doc 7. Unquoted Special Characters in Strings
What happens: Strings containing {}, [], ,, &, *, !, |, >, %, @, or backticks get misinterpreted.
# BROKEN
message: Hello {name}! # triggers flow mapping
path: C:\Users\name # \U is a unicode escape
expression: a || b # || is treated as a special token
# FIXED
message: "Hello {name}!"
path: "C:\\Users\\name"
expression: "a || b" Real-World Impact: YAML Errors in Production
YAML syntax errors aren't just academic — they cause real outages. Here are scenarios we've seen repeatedly:
- Kubernetes Deployment Failure: A team deploys a new service but the pod stays in
CrashLoopBackOff. The cause? A tab character in the ConfigMap YAML that was invisible in their editor. The fix: configure all team editors with"editor.insertSpaces": true. - GitHub Actions Silent Failure: A workflow step runs but produces unexpected results. The
ifcondition withenv.DEPLOY == 'yes'always evaluates to true because YAML 1.1 parsedyesas booleantrue. The fix: always quote string values that could be misinterpreted. - Docker Compose Port Mismatch: A developer adds a new service but indents the
portskey underenvironmentinstead of the service root. Docker Compose silently ignores the misplaced key. The service starts without exposed ports. - Helm Chart Merge Conflict: Two developers modify the same values file. After resolving git conflicts, inconsistent indentation causes the parser to read keys at the wrong nesting level. The application starts with default values instead of overrides.
YAML Error Prevention Checklist
Before committing any YAML file to production, run through this checklist:
- Editor configured: Spaces only (no tabs), 2-space indent, show invisible characters
- Consistent indentation: Every level uses the same number of spaces throughout the file
- Colons have trailing spaces: Every
key: valuepair has a space after the colon - Ambiguous values quoted: Country codes, version strings, yes/no values all wrapped in quotes
- Anchors resolve correctly: Every
*aliashas a matching&anchordefined earlier in the document - Document separators clean:
---on its own line, no content after... - Special characters escaped: Strings with
,[], or backslashes are double-quoted - Validated with a linter: Run through our YAML formatter or
yamllintbefore committing
For a comprehensive YAML syntax reference, see our YAML Syntax Guide.
YAML Linting and Validation Tools
Preventing YAML errors starts with proper tooling. Here are the most effective linting and validation tools used in production environments:
- yamllint: The standard Python-based YAML linter. Checks syntax, indentation, line length, and trailing spaces. Configurable via
.yamllintfile. Integrates with pre-commit hooks and CI pipelines. - Prettier: While primarily a code formatter, Prettier's YAML plugin (
prettier-plugin-yaml) enforces consistent formatting across your project. - VS Code YAML Extension: Red Hat's YAML extension provides real-time validation, auto-completion, and schema support directly in your editor.
- kubeval / kubeconform: Kubernetes-specific validators that check your manifests against the API schema. They catch structural errors that a generic YAML linter would miss.
- Online validators: Our YAML Formatter provides instant browser-based validation with precise error locations — no installation required.
The most effective strategy is layered: use editor extensions for instant feedback, yamllint in pre-commit hooks for code review, and a validator in CI/CD as a final safety net. This three-layer approach catches virtually all YAML errors before they reach production.
YAML Key Naming Conventions
While YAML allows almost any string as a key, following naming conventions prevents subtle bugs and improves readability:
- Use lowercase with underscores:
database_timeoutis clearer thandatabaseTimeoutorDatabaseTimeout. Most YAML style guides recommend snake_case. - Avoid special characters in keys: Keys containing colons, brackets, or quotes require escaping and are easy to mistype. Prefer simple alphanumeric keys with underscores.
- Don't use numeric keys unless necessary: Numeric-looking keys (
123,1.0) may be parsed as numbers instead of strings. If you must use them, quote them:"123". - Be consistent within a file: Don't mix
camelCaseandsnake_casein the same configuration. Consistency reduces cognitive load and prevents duplicate-key bugs. - Use descriptive names:
max_connection_retriesis self-documenting.mcris not. Configuration files are often read by people who didn't write them.
These conventions aren't enforced by the YAML specification, but they're widely followed in the Kubernetes, Docker, and CI/CD ecosystems. Following them makes your configuration files easier to review, debug, and maintain.
Frequently Asked Questions
How do I validate YAML files quickly?
The fastest way is to paste your YAML into an online validator like our YAML Formatter. It checks syntax, highlights errors with line numbers, and suggests fixes — all in your browser with no upload. For CI/CD integration, use yamllint (Python) or prettier with the YAML plugin.
Why does my YAML work locally but fail in CI?
This usually indicates a parser version mismatch. Your local tool might use YAML 1.2 while CI uses YAML 1.1 (or vice versa). Common symptoms: yes/no being treated as booleans, or octal numbers parsing differently. Always use true/false for booleans and quote ambiguous values.
What's the most common YAML error?
Tab characters instead of spaces. It's invisible in most editors and causes immediate parse failures. The second most common is missing space after colons (key:value instead of key: value). Both are caught instantly by any YAML linter.
Can YAML have duplicate keys?
The YAML specification says keys should be unique, but many parsers silently use the last value when duplicates exist. This leads to subtle bugs where configuration appears to be set but is actually overridden. Always validate for duplicate keys before deploying.
How do I debug a large YAML file?
Start by validating the entire file with a linter to get the first error location. Fix that error and re-validate — YAML errors cascade, so one fix often resolves multiple reported issues. For Kubernetes manifests, use kubectl apply --dry-run=client -f file.yaml to validate without deploying.
The Fastest Way to Find and Fix YAML Errors
Stop debugging YAML manually. Use our YAML validator and formatter to catch all seven of these errors instantly with precise line and column numbers. Paste your YAML, see the error highlighted, fix it, and copy the clean output — all in your browser, zero server upload. For more on YAML syntax, check out our YAML vs JSON vs TOML comparison.