PRACTICAL GUIDE
JSON vs CSV: Differences, Use Cases and Conversion Tips
One holds shape, the other holds a table. Knowing which problem you have decides the format, and decides what breaks when you convert between them.
Last updated
One carries structure, the other carries a table
JSON describes shape. A value can be a number, a string, a boolean, null, a list or another object, and that is recorded in the data itself. Anything reading it knows that 007 is a string and 7 is a number without being told.
CSV describes a grid. Every cell is text, every row has the same columns, and there is nothing else. That constraint is the whole point: it opens in any spreadsheet, streams a row at a time regardless of size, and has no version or dialect to negotiate.
Nesting is where the conversion actually fails
A flat list of objects with identical keys converts to CSV cleanly. Anything else forces a decision that no tool can make for you. An object inside an object can be flattened into columns joined by a dot; an array can become several columns, or one column of joined values, or several rows.
Each of those answers is right for some question and wrong for others, which is why converters that guess produce output that looks fine and is subtly wrong. Decide what the nested values should become before you convert, not after.
The types do not survive the trip
Everything in a CSV is text. Numbers, booleans and nulls come back as the strings that were written, and an empty cell is genuinely ambiguous: it could be an empty string, a null, or a value that was never set. Converting JSON to CSV and back does not return what you started with, and the differences are the kind that surface much later.
The classics that corrupt a CSV
A comma inside a value needs the value quoted; a quote inside a quoted value needs doubling. Spreadsheets add their own problems on top: a leading zero disappears, a value like 1-2 becomes a date, and a long identifier turns into scientific notation. None of that is CSV's fault, but all of it happens to CSV files, which is the argument for validating a converted file rather than trusting it.
Which to choose
If the consumer is a spreadsheet, a database import or a person, use CSV. If the consumer is code, or the data has any shape at all, use JSON. If both, the usual answer is to keep JSON as the source of truth and generate CSV on demand, because that direction loses information in a controlled way while the reverse has to invent it.
Frequently asked questions
Which is smaller?
CSV, comfortably, because it writes each column name once at the top instead of repeating every key on every record. For a large flat dataset that is a substantial difference. Once compressed the gap narrows sharply, since the repeated keys in JSON are exactly what a compressor is good at removing.
How should nested JSON be flattened?
Objects flatten reasonably into dotted column names, so address.city becomes a column. Arrays have no good answer: joining them into one cell loses the ability to work with the items, and splitting them into rows multiplies every other field. Decide deliberately, and if the arrays matter, keep the JSON.
Is my data uploaded when I convert it?
No. Both converters run in your browser and the text never leaves your device. That is the difference that matters when the file is an export containing customer records or anything else you would rather not paste into an unknown website.
Why does my CSV break when a value contains a comma?
Because the comma is the separator, so the value has to be wrapped in double quotes for a reader to know where it ends. A quote inside such a value is escaped by doubling it. A converter should do this for you; a file assembled by hand or by string concatenation usually does not.