JSON vs YAML vs CSV - Which Data Format to Use When

JSON, YAML, and CSV all store structured data, but they are not interchangeable. The same person record looks tidy in all three - until you need nested addresses, typed booleans, comments in config, or a spreadsheet your teammate can open in Excel. Pick the wrong format and you lose types, flatten trees into awkward columns, or hit a parser surprise like YAML turning the country code NO into false. This guide puts JSON vs YAML vs CSV side by side, shows when each one wins, and links the free converters on ToolsMinify.

The same record in all three formats

Start with one object: an id, a name, an active flag, and tags. Here is how that record looks in each format so you can compare syntax at a glance.

JSON

• {"id": 42, "name": "Ada", "active": true, "tags": ["admin", "beta"]}
• Quoted keys, commas between fields, square brackets for arrays, true/false/null as literals.
• No comments. Trailing commas are invalid in standard JSON.

YAML

• id: 42
• name: Ada
• active: true
• tags:
• - admin
• - beta
• Indentation defines structure. Quotes are often optional. Comments start with #.

CSV

• id,name,active,tags
• 42,Ada,true,"admin;beta"
• One header row, then one row per record. Nested arrays become a flattened string or extra columns. No native types beyond text.

Already looking at a JSON array of objects? Paste it into the JSON to CSV Converter to produce a spreadsheet-friendly table. Moving config the other way? Use the YAML to JSON Converter before an API client that only speaks JSON.

JSON: the API and interchange default

JSON (JavaScript Object Notation) is a subset of JavaScript object syntax that every major language can parse. Objects, arrays, strings, numbers, booleans, and null are first-class. Nesting is unlimited, so an address object inside a user object is natural. That is why REST and GraphQL responses, webhook bodies, and many config stores ship JSON.

• Best for: API request and response bodies, browser and mobile clients, message queues, anything that must round-trip through many languages.
• Strengths: strict grammar, predictable types, excellent tooling, easy to minify and pretty-print.
• Limits: no comments, no multi-line strings without escaping, no anchors or merges. Humans editing large JSON by hand get noisy diffs.

When a payload arrives as one compressed line, open the JSON Minifier & Formatter to beautify it, validate braces, then minify again before you ship.

YAML: config people actually edit

YAML (YAML Ain't Markup Language) is designed for humans first. Indentation replaces most braces. You can leave comments with #, write multi-line blocks with | or >, and reuse blocks with anchors (&name) and aliases (*name). That combination made YAML the default for Kubernetes manifests, Docker Compose, GitHub Actions, and many app config files.

Comments and anchors

Comments are the feature JSON lacks. A line starting with # documents why a timeout is 30 seconds without changing runtime data. Anchors go further: define a shared logging block once with &logging, then pull it into several services with *logging, optionally overlaying keys with <<:. Used carefully, anchors cut duplication. Used carelessly, they make files hard to read and surprising to merge in Git.

• Best for: deployment and CI config, feature flags that humans edit, small documents where readability beats wire size.
• Strengths: comments, anchors/aliases, multi-line strings, less punctuation noise.
• Limits: indentation bugs, implicit typing surprises, and a larger attack surface if you parse untrusted YAML with unsafe loaders.

CSV: flat tables for spreadsheets

CSV (Comma-Separated Values) is a grid: columns and rows. Spreadsheets, BI tools, and data pipelines understand it. There is no nested object, no array type, and usually no boolean type - everything is text until your importer casts it. That is fine when your data is already a table of users or orders. It breaks down when the source is a tree.

Why CSV loses types and nesting

• Types: "42", 42, and true all arrive as strings unless you define a schema. Leading zeros in ids and phone numbers get stripped by Excel.
• Nesting: an address with street and city becomes address.street columns, a JSON blob in one cell, or duplicated parent rows.
• Arrays: tags often become a single cell with a delimiter (admin;beta), which you must split later.
• Null vs empty: an empty cell might mean null, empty string, or missing column - conventions differ.

If your source is nested JSON, convert deliberately with the JSON to CSV Converter and decide how arrays and nested keys should flatten before you hand the file to a spreadsheet.

When each format is the right choice

APIs and machine-to-machine

Prefer JSON. Clients expect application/json, tooling is everywhere, and the type system is good enough for most contracts. YAML as an HTTP body is rare and usually a mistake. CSV as an API response only makes sense for bulk export endpoints that feed Excel or data warehouses.

Config files

Prefer YAML (or a typed format like TOML) when humans edit the file and need comments. Prefer JSON when the config is generated, validated by a schema, or edited mostly by tools. Keep YAML documents small and reviewed - deep anchors and custom tags age poorly.

Spreadsheets and analytics

Prefer CSV (or a real spreadsheet format) when the consumer is Excel, Google Sheets, or a SQL COPY. Flatten your model first. Keep JSON for the system of record and export CSV as a view.

Classic traps

YAML's Norway problem

In YAML 1.1, several unquoted strings are parsed as booleans: yes, no, on, off, true, false (and some locale variants). The country code NO for Norway becomes boolean false. Version strings like 1.10 can become floats. Quote values that look like booleans, numbers, or dates when they are really strings: country: "NO". Prefer YAML 1.2 parsers when you can, and still quote suspicious scalars.

CSV commas inside quoted fields

Fields that contain commas, quotes, or newlines must be wrapped in double quotes. A quote inside a field is escaped by doubling it: "Ada ""Lovelace""". A naive split on commas breaks those rows. Always use a real CSV parser or exporter - including when you round-trip through the JSON to CSV Converter. Locale settings also matter: some regions use semicolon separators while Excel still expects commas or vice versa.

Other gotchas

• JSON: trailing commas and comments from JavaScript object literals fail strict parsers.
• YAML: tabs vs spaces, unsafe loaders that execute tags, and huge documents that hide merge mistakes.
• CSV: no single standard for encoding, delimiter, or line endings; always document UTF-8 and your separator.

Side-by-side comparison

• Nesting - JSON and YAML: natural trees. CSV: flatten or lose structure.
• Types - JSON: string, number, bool, null, array, object. YAML: richer scalars (plus surprises). CSV: text until cast.
• Comments - JSON: none. YAML: # comments. CSV: no standard comments.
• Human edit - YAML usually wins; JSON is okay for small files; CSV wins inside spreadsheets.
• Wire / API - JSON is the default. YAML and CSV are edge cases.
• Tooling - convert with JSON to CSV and YAML to JSON; format JSON with the JSON Minifier & Formatter.

Frequently asked questions

Is YAML better than JSON?

For human-edited config with comments, often yes. For APIs and interchange, JSON is better: stricter, more predictable, and universally supported. Many teams author YAML and compile or convert to JSON for runtime.

Can CSV represent nested JSON?

Only by flattening. Nested objects become dotted columns or JSON-in-a-cell strings; arrays become delimited lists or repeated rows. Use CSV when the consumer needs a table, not when you need to preserve the full tree.

Should I store config in JSON or YAML?

If people edit it weekly and leave comments, YAML (or TOML). If a schema validator or codegen owns the file, JSON. Avoid mixing both for the same source of truth.

What is the Norway problem in YAML?

Unquoted NO (and similar tokens) can parse as boolean false in YAML 1.1. Quote country codes and other stringy scalars, or use a YAML 1.2 parser that treats them as strings.

How do I convert between these formats?

Use the YAML to JSON Converter for config to API shape, and the JSON to CSV Converter for tabular export. Beautify or minify JSON with the JSON Minifier & Formatter. All three run in your browser.

Convert JSON, YAML, and CSV on ToolsMinify

Every tool below runs entirely in your browser - free, no signup, nothing uploaded:

• JSON to CSV Converter - turn a JSON array of objects into a downloadable CSV table.
• YAML to JSON Converter - parse YAML config into JSON for APIs and validators.
• JSON Minifier & Formatter - pretty-print or minify JSON and catch syntax errors early.
• All converter tools - the full category index.