JSON vs YAML vs CSV vs TOML: Which Data Format Should You Use?

Most projects juggle all four of these formats sooner or later — JSON from APIs, YAML in CI and Kubernetes, CSV from spreadsheets, TOML in tools like Cargo and Pyproject. Picking the right one is mostly about who (or what) has to read it.

At a glance

Format	Best for	Comments allowed	Native types
JSON	APIs, data interchange	No (without extensions)	string, number, bool, null, array, object
YAML	Human-edited config	Yes (#)	all JSON types + dates, multiline
CSV	Tabular data, exports	No standard	everything is a string
TOML	App/build config	Yes (#)	typed (ints, floats, dates, arrays, tables)

The same data, four ways

A small config record:

JSON — strict, quoted keys, no trailing commas:

{
  "name": "devtools",
  "version": "1.0.0",
  "tags": ["seo", "tools"],
  "published": true
}

YAML — indentation-based, unquoted strings, comments:

# Site config
name: devtools
version: 1.0.0
tags:
  - seo
  - tools
published: true

CSV — flat, one record per line, values comma-separated:

name,version,published
devtools,1.0.0,true

TOML — sectioned, typed values, comments:

# Site config
name = "devtools"
version = "1.0.0"
tags = ["seo", "tools"]
published = true

When to use JSON

JSON is the lingua franca of the web. Every language parses it, every API speaks it, and it is the only format you can use directly inside JavaScript without a parser. Its rigidity (no comments, quoted keys, strict commas) is a feature when machines are the audience. Use it for API payloads, package.json, and any data that crosses a process boundary.

When to use YAML

YAML is the config format when humans write it. Comments, multiline strings, anchors, and a compact nested syntax make it readable for long configs. That is why CI pipelines, Docker Compose, and Kubernetes all use it. The cost is its sharp edges: indentation errors silently break things, and the "Norway problem" (country code no parsed as boolean false) still bites people. Validate it — the YAML Validator catches the common mistakes.

When to use CSV

CSV is for tabular data and spreadsheet interchange. It is the only format here that does not nest — every row is a flat record. That limitation is its strength: spreadsheets, databases, and analytics tools all import and export it natively. When a JSON array of objects is really just a table, CSV to JSON (and back) is the bridge.

When to use TOML

TOML is config for applications and build tools — Cargo, Poetry, PDM, and many CLIs. It keeps YAML's human-friendliness but is stricter and fully typed, so 1.0.0 stays a string and a date stays a date. For medium-complexity app config it is often the nicest choice.

A rule of thumb

• Machines talking to machines → JSON
• Humans writing long config → YAML (validate it)
• A table of rows → CSV
• App or library config → TOML

You will rarely commit to one. The practical skill is converting between them quickly — reformat with the JSON Formatter, move between JSON and YAML with the JSON to YAML Converter, and turn spreadsheets into objects with CSV to JSON.