JSON, CSV or XML: Choosing a Data Format You Will Not Regret
Three formats, three different jobs. What each can and cannot express, the conversions that lose information, and how to pick without repenting later.
Updated August 11, 20265 min read
These three formats are not competitors so much as answers to different questions. CSV is a table. JSON is an object graph. XML is a document with markup. Most of the pain in data work comes from asking a format to be something it is not — nesting inside CSV, tables inside XML, comments inside JSON — and the cure is usually to change format rather than to fight it.
What each one can express
| CSV | JSON | XML | |
|---|---|---|---|
| Shape | Flat rows and columns | Nested objects and arrays | Nested elements |
| Types | None — everything is text | String, number, boolean, null | None natively; schema can add them |
| Comments | No | No | Yes |
| Attributes vs content | N/A | No distinction | Yes — a real difference |
| Size | Smallest | Middling — keys repeat | Largest — tags repeat twice |
| Streaming huge files | Trivial | Awkward | Workable |
The row that causes most surprise is comments in JSON. The specification has none, and a // line makes the file invalid — which is why so many tools invented their own dialects (JSON5, JSONC) to work around it. If a config file needs explaining, that is a genuine reason to prefer something else.
Choosing by destination
- 1Going into a spreadsheet, database or analysis tool? CSV. Universally supported, compact, and the tabular shape is what those tools expect.
- 2Going into an API or a web application? JSON. It carries types, expresses nesting, and every language parses it without a library decision.
- 3Talking to an enterprise or government system? Probably XML, because that is what the specification will say. Do not fight it.
- 4A configuration file people will edit by hand? Not JSON — no comments and unforgiving syntax. YAML or TOML are kinder.
- 5Millions of rows? CSV, processed line by line. Whole-file JSON parsing of a multi-gigabyte document is a memory problem.
What each conversion loses
| Conversion | What is lost |
|---|---|
| CSV → JSON | Nothing structurally, but everything arrives as strings unless types are inferred |
| JSON → CSV | Nesting. Objects and arrays must be flattened or dropped |
| XML → JSON | Attribute-versus-element distinction, comments, ordering guarantees |
| JSON → XML | Nothing, but the result is verbose and needs a naming convention |
| Excel → CSV | Formulas, formatting, multiple sheets — see Excel to CSV and JSON |
The JSON-to-CSV row is the one that bites. Flattening {customer: {name, address: {city}}} into columns needs a convention — customer.address.city is common — and anything that is a list has no good answer at all. If your JSON is genuinely nested, exporting to CSV is a lossy decision, not a format change.
The type problem going the other way is quieter and just as damaging. CSV has no types, so 007 may arrive as the number 7, 2026-04-03 may become a date in the wrong locale, and TRUE may or may not become a boolean. Those are the same failures described in converting Excel to CSV and JSON, and they are inherent to the format rather than to any particular tool.
Pretty print, validate and explore on your own device. Customer data and API payloads are never uploaded.
Format and inspect JSONPractical habits
- Validate before you ship. A trailing comma or unescaped quote is rejected by the receiving system with an error that rarely points at the real line. The validator finds it in seconds.
- Use ISO dates everywhere.
2026-04-03is unambiguous in every locale and sorts correctly as plain text. Nothing else is. - Encode as UTF-8, always. Anything else turns accented names and currency symbols into mojibake on another system.
- Keep identifiers as strings. Postcodes, phone numbers and account numbers are labels, not quantities — treating them as numbers strips leading zeros and rounds long values.
- Sort keys for diffing. Two exports of the same data with keys in different orders produce a diff full of noise. The key sorter makes changes readable.
Minify or pretty print?
Both, at different times. Pretty printed JSON — indented, one value per line — is for humans reading and for version control, where line-by-line diffs are the whole point. Minified JSON strips every unnecessary space and is for transmission, where it typically saves 20–30% before compression.
The mistake is committing minified JSON to a repository. Every change then appears as one enormous modified line, and reviewing it is impossible. Store it readable, minify at build or send time.
All of these tools run on your own device, which matters for data work specifically: a JSON payload or CSV export is often the most sensitive file an organisation handles, and uploading one to an online formatter is a disclosure regardless of what the service promises to do with it.
Frequently asked questions
Should I use JSON or CSV?
CSV for tabular data going into spreadsheets, databases or analysis tools — it is compact and universally supported. JSON when the data is nested or when types matter, such as an API payload, because CSV cannot express a list inside a record and treats every value as text.
Is JSON replacing XML?
For web APIs, largely yes — JSON is lighter and maps directly onto the data structures programming languages already use. XML remains standard in enterprise, government, publishing and document formats, where its schemas, namespaces and attribute model do real work.
Can JSON have comments?
No. The specification has no comment syntax, and adding one makes the file invalid. That is why variants like JSON5 and JSONC exist. If people need to edit and understand the file by hand, YAML or TOML are better choices for configuration.
What happens to nested data when I convert JSON to CSV?
It has to be flattened, usually into dotted column names like `customer.address.city`, and lists inside a record have no clean representation at all. If your JSON is genuinely nested, exporting to CSV is a lossy decision rather than a simple format change.