JSON vs YAML

JSON vs YAML — The Bottom Line

Use JSON for APIs, data interchange, and machine-generated data. Use YAML for config files written and maintained by humans. YAML is a superset of JSON — every JSON document is valid YAML, but not vice versa.

Side-by-Side Example

JSON (168 chars)

json
{
  "server": {
    "host": "localhost",
    "port": 8080,
    "debug": true
  },
  "database": {
    "url": "postgresql://localhost/mydb",
    "maxConnections": 10
  },
  "features": ["auth", "logging", "metrics"]
}

YAML (115 chars)

yaml
server:
  host: localhost
  port: 8080
  debug: true

database:
  url: postgresql://localhost/mydb
  maxConnections: 10

features:
  - auth
  - logging
  - metrics

Detailed Comparison

FeatureJSONYAML
SyntaxBraces, quotes, commasIndentation, colons
CommentsNot supported# line comments
Multiline stringsEscape \n| literal, > folded blocks
Data types6 typesMany (dates, binary, etc.)
Anchors / aliasesNoYes — &anchor and *alias
Human readabilityModerateHigh — less punctuation
Machine parsingFasterSlower (complex spec)
StrictnessStrict specSpec has edge cases
Browser nativeJSON.parse()Needs library (js-yaml)
File sizeLarger (quotes)Smaller (no quotes needed)
Schema supportJSON SchemaLimited native support
Common useREST APIs, configKubernetes, Docker, CI/CD

When to Use JSON

  • REST APIs — standard data interchange format, supported natively in every language
  • Machine-generated data — serializing objects, databases, caches
  • Browser environments — native JSON.parse() / JSON.stringify()
  • Strict validation — JSON Schema is mature and well-tooled
  • Simple configs — package.json, tsconfig.json, composer.json

When to Use YAML

  • Kubernetes manifests — deployment.yaml, service.yaml, ingress.yaml
  • CI/CD pipelines — GitHub Actions, GitLab CI, CircleCI
  • Docker Compose — docker-compose.yml
  • Ansible playbooks — infrastructure as code
  • Application configs — Spring application.yml, Rails database.yml
  • Docs with frontmatter — Hugo, Jekyll static sites

YAML Gotchas

yaml
# Booleans in YAML 1.1 (old parsers):
yes: true     # "yes" is a boolean!
no: false     # "no" is a boolean!
on: true      # "on" is a boolean!

# Octal numbers:
mode: 0755    # parsed as 493 (octal), not 755!

# Norway problem:
country: NO   # NO is a boolean "false" in YAML 1.1

# Fix: quote everything that looks ambiguous
mode: "0755"
country: "NO"

Frequently Asked Questions

Yes — technically every valid JSON file is also valid YAML 1.2. This means you can use YAML parsers to read JSON files, but the reverse is not true.

JSON parsing is significantly faster. JSON has a simple grammar; YAML is a complex spec. For performance-critical paths (API responses, caching), use JSON.

Yes — use JSONKit's YAML to JSON converter. Be aware that YAML-specific features (anchors, dates, multiline strings) may require special handling.

Kubernetes configs are written by humans and committed to git. YAML comments, anchors, and cleaner syntax make large manifests more maintainable than equivalent JSON.

No — the official JSON spec does not support comments. Use JSON5, JSONC (JSON with Comments), or a preprocessor if you need commented config files.

Related Tools