CSV vs JSON vs XML: Which Data Format Should You Use?

CSV is a table written as text: rows separated by line breaks, fields separated by a comma, quotes around anything containing a comma or a newline. That is the whole specification, and its ambiguity is both its strength and its weakness. It needs no library, it opens in any spreadsheet, and every language can parse it in a few lines.

What it cannot express is structure. A column holds one value per row. Nested objects, lists of things, mixed types and missing-versus-empty all have to be squeezed into a convention — a JSON blob in a cell, comma-separated values in one field, an empty string standing in for null. Each of those is a decision someone has to know about when reading the file back.

It also has encoding and delimiter traps. Files exported from Excel on Windows often arrive as CP-1252 rather than UTF-8, so accented characters turn into mojibake. European locales export with a semicolon instead of a comma. And a single unescaped quote can shift every subsequent row by one column.

JSON represents the same records as nested objects and arrays, so a list of tags is a list rather than a string someone split on commas. It is self-describing, handles missing values explicitly, and is the native dialect of web APIs. Its cost is verbosity — keys repeat in every record — and the fact that spreadsheets do not open it directly.

XML solves similar problems with a heavier tool: attributes, namespaces, schema validation and a mature ecosystem for documents that must be formally described. It dominates in enterprise interchange, publishing and formats like SVG, DOCX and SVG that are XML underneath. For an API in 2026, JSON is the default; for a contract that needs a published schema, XML still earns its keep.

CSV to JSON is easy in one direction and lossy in the other. Going up, each row becomes an object keyed by the header — but every value arrives as a string unless you infer types, so a column of numbers becomes text and a column of dates becomes a pattern of characters. Going back down, something has to decide what a nested object becomes: a JSON blob in a cell, or flattened columns with dotted names.

Before converting, check four things: the encoding (UTF-8 with or without BOM), the delimiter, whether the first row is a header, and how missing values are written. Get those right and the round trip is faithful. Get them wrong and the conversion will succeed technically while quietly shifting columns.

For anything with real nesting, convert to JSON and keep it there. Flattening a nested structure into a spreadsheet is a one-way trip unless you preserve the original alongside the export.