JSON, YAML, or CSV: pick the right container
Three formats, three jobs. When each one shines, when each one bites, and why "it depends" has an actual answer.
5 min read · Reviewed July 2026
These three formats get treated as interchangeable because converters exist (there's one on this page). They're not. Each was shaped by a different job, and using the wrong one is a slow leak of small annoyances.
JSON is the format of machines talking to machines. Strict syntax, real types, universal parser support — every API speaks it. Its weaknesses are human ones: no comments, unforgiving punctuation, and deep nesting that's miserable to read. If software writes it and software reads it, JSON.
YAML: configs humans maintain
YAML is JSON's superset optimized for human eyes: indentation instead of braces, comments allowed, less punctuation noise. That's why Kubernetes, CI pipelines, and Docker Compose all chose it — config files are read and edited by people far more often than they're parsed. The cost is a parser full of clever guesses that occasionally guess wrong (see our Norway problem guide). Rule: YAML for files humans edit, never for data machines exchange.
CSV: tables, and nothing but tables
CSV is older than both and will outlive both, because it does one thing with zero ceremony: rows and columns as plain text. Every spreadsheet, database, and data tool imports it. It has no types, no nesting, no standard worth the name — but when the data IS a table and a human needs it in Excel, CSV is the answer and everything else is friction.
The conversion flow on this page reflects real life: APIs hand you JSON, your finance person wants CSV, your deployment wants YAML. Same data, three costumes — just know which room each costume belongs in.