YAML Validator

1. Mixed tabs and spaces

YAML allows only spaces, never tabs. Editors that auto-insert tabs cause silent failures. Configure your editor to expand tabs to spaces in .yaml / .yml files.

2. Missing colons after keys

# Wrong
name myapp
version: 1.0

# Right
name: myapp
version: 1.0

3. Inconsistent indentation

Each level must use the same number of spaces. 2 spaces, then 4 spaces for the nested level breaks parsing. Pick 2 or 4 spaces and stick with it.

# Wrong (2 → 4 spaces)
parent:
  child:
      grandchild: value

# Right (consistent 2 spaces)
parent:
  child:
    grandchild: value

4. Unquoted special characters

Colons, hashes, and certain prefixes have meaning in YAML. Quote any value containing them:

# Breaks!
url: http://example.com:8080
note: # this is a comment, lost!

# Quoted
url: "http://example.com:8080"
note: "# preserved"

5. The Norway problem

Country code NO (Norway), yes,off, on are coerced to booleans in YAML 1.1 (default in many parsers). Always quote string values that look like booleans: "NO", "yes".

6. Trailing whitespace

Trailing spaces after a value can cause parsing issues in some implementations. Configure your editor to trim_trailing_whitespace for .yaml.

Anchors and aliases (DRY)

defaults: &defaults
  timeout: 30
  retries: 3

server1:
  <<: *defaults
  host: server1.example.com

server2:
  <<: *defaults
  host: server2.example.com

&name defines an anchor; *name references it. Avoid duplicate values across the file.

Multi-line strings (literal vs folded)

# Literal — preserves newlines (|)
script: |
  echo "hello"
  echo "world"
# Result: "echo \"hello\"\necho \"world\"\n"

# Folded — joins with spaces (>)
description: >
  This is a long
  description that wraps
# Result: "This is a long description that wraps\n"

Multi-document files

# Multiple YAML documents in one file
---
kind: Service
metadata:
  name: my-service
---
kind: Deployment
metadata:
  name: my-deploy

Common in Kubernetes manifests — one file containing Service, Deployment, Ingress, etc.

Inline (flow) syntax

# Flow style — looks like JSON
ports: [80, 443]
env: {DEBUG: false, LOG_LEVEL: info}

# Block style — typical YAML
ports:
  - 80
  - 443
env:
  DEBUG: false
  LOG_LEVEL: info

Tags (explicit types)

# Force string type
version: !!str 1.0       # "1.0" not 1.0
amount: !!float 100      # 100.0 not 100
date: !!timestamp 2024-01-01

Does this support all YAML features?

Common patterns yes — mappings, sequences, scalars, nested structures, block scalars (| / >), comments. Anchors / aliases work for parsing but are inlined when converted to JSON. Multi- document YAML is not fully supported in conversion.

Is my data safe?

Yes. All processing happens in your browser. Nothing is sent to any server — verify in DevTools Network tab. Safe for sensitive Kubernetes manifests, secrets, and production configs.

Why is my GitHub Actions YAML rejected?

GitHub uses a strict YAML parser. Common issues: tabs in indentation, missing colons after step names, unquoted expressions like ${{ secrets.TOKEN }} with special chars. Validate here first to catch syntax errors before pushing.

What's the difference between .yaml and .yml?

Both are valid YAML extensions. .yaml is the official spec recommendation; .yml exists for historical reasons (DOS 8.3 filename limit). Many tools accept both. Pick one for consistency in a project.

Can I use YAML for everything instead of JSON?

Not recommended for APIs (slower parsing, more ambiguity). YAML excels for human-edited configs; JSON excels for machine-to-machine. Common pattern: YAML for source of truth (e.g., dbt models), generate JSON for runtime consumption.