What a JSON file actually looks like
Here is a real JSON file: two customer records. Read it slowly once, because every concept in this guide points back to it.
The whole file is an array, marked by square brackets [ ], holding two objects. Each object, marked by curly braces { }, is one record. Inside an object, data lives in key-value pairs: "id": 101 means the key "id" holds the value 101, and keys are always quoted strings.
The values keep their types, and this is one of JSON's superpowers. "Amelia Chen" is a string (text, in quotes). 101, 2023, and 4 are numbers (no quotes). true and false are booleans. null is an explicit "no value here", which is different from an empty string: lastNote is null for Amelia, meaning the field exists but has no value, while Bruno's lastNote holds the text "Call, don't email".
Then comes nesting, the reason JSON exists. "address" is an object inside the customer object, with its own keys city and state. "tags" is an array inside the customer object, holding two strings. JSON nests arbitrarily deep: objects inside arrays inside objects, as far as your data goes. Whitespace is irrelevant, so the pretty-printed version above and a minified single-line version are the same data. One quirk worth knowing: if a key appears twice in one object, the last value wins and the first is silently lost. Verified with JSON.parse on the build machine: {"a":1,"a":2} parses to 2. It rarely happens in practice, but when it does, nothing warns you.
[
{
"id": 101,
"name": "Amelia Chen",
"email": "amelia@example.com",
"vip": true,
"signupYear": 2023,
"address": { "city": "Austin", "state": "TX" },
"orders": 4,
"tags": ["newsletter", "referral"],
"lastNote": null
},
{
"id": 102,
"name": "Bruno Almeida",
"email": "bruno@example.com",
"vip": false,
"signupYear": 2024,
"address": { "city": "São Paulo", "state": "SP" },
"orders": 1,
"tags": ["newsletter"],
"lastNote": "Call, don't email"
}
]What a CSV file actually looks like
Now the same two records as CSV. This output was produced by the converter on this page from the JSON above, with flattening on, so what you see is exactly what the conversion does, not an illustration.
The first line is the header row: the column names. Every line after it is one record, with values in the same order, separated by commas. That is the whole format: header, rows, delimiter. Ten columns, two rows, no nesting anywhere.
Everything is text now, and that is the defining trait of CSV. 101, true, and 2023 look like a number and booleans, but the file does not know that: they are characters, and whatever opens the file decides what they mean. The empty cell at the end of Amelia's row is her null lastNote: null became nothing. Her two tags became one cell, "newsletter; referral", joined with "; ". And Bruno's note is wrapped in quotes, "Call, don't email", because it contains a comma: quoting is how CSV protects a value that contains the delimiter.
The address object became two columns, address.city and address.state. This dot-notation flattening is exactly what converters do, and our flattening guide explains the toggle behind it in full. Notice what the CSV cannot say anymore: that city and state belonged to one address object, or that newsletter and referral were two separate tags rather than one string with a semicolon. The shape is gone. The values remain.
id,name,email,vip,signupYear,address.city,address.state,orders,tags,lastNote
101,Amelia Chen,amelia@example.com,true,2023,Austin,TX,4,newsletter; referral,
102,Bruno Almeida,bruno@example.com,false,2024,São Paulo,SP,1,newsletter,"Call, don't email"The five differences that actually matter
Same data, two philosophies. Five differences decide which format you reach for, and they explain nearly every "which should I use" argument you will ever hear.
First, shape: JSON is a tree, CSV is a table. JSON can hold an order containing a customer containing an address containing a list of items, nesting as deep as reality goes. CSV has exactly one level: rows and columns. Anything deeper must be flattened into dot-notation columns or serialized into a cell as text, and either way the original structure is no longer really there.
Second, types: JSON distinguishes 2023 the number from "2023" the text, and true the boolean from "true" the string. CSV stores characters; interpretation happens later, in whatever opens the file. This is why the string "007" arrives in a CSV as the characters 007 (verified on this page's converter), yet a spreadsheet may still display it as 7 when you open the file: the CSV kept the text faithfully, and Excel made its own guess on top. The format did its job; the viewer added an opinion.
Third, schema: JSON is self-describing. Every record carries its own keys, so records are allowed to differ: one customer can have a "notes" field the others lack, and the file is still perfectly valid. CSV's schema lives in the header row and assumes uniformity. A row with an extra value has nowhere documented to put it, and ragged data, where rows carry different fields, becomes a column-alignment puzzle instead of a non-issue.
Fourth, hand-editing: JSON punishes small mistakes loudly. One missing comma or quote makes the entire file invalid, which is annoying but honest, and it is why JSON validators exist. CSV punishes small mistakes quietly. One unquoted comma inside a value shifts every column after it, and the file still opens, just wrong. When you are editing by hand, loud failure beats silent corruption.
Fifth, producers: formats follow their producers. APIs, apps, databases, and logs emit JSON because they think in nested structures with types. Spreadsheets, business exports, and email attachments are CSV because humans think in tables. When someone hands you a file, its format usually tells you which world it came from, and converting is how the two worlds talk to each other.
What converting JSON to CSV actually does
Converting is flattening: projecting the tree onto a table. Every claim in this section was verified on the build machine against the exact conversion engine this page runs, so these are the real rules, not the idealized ones.
With flattening on, the engine applies six rules. Nested objects become dot-notation columns: address.city, address.state. Lists of simple values become one cell joined with "; ": newsletter and referral became "newsletter; referral". Null becomes an empty cell. An empty list also becomes an empty cell, which means null and an empty list are indistinguishable after conversion. An empty object becomes the literal text {}. Numbers and booleans become their text forms: 2023 becomes the characters "2023".
The sixth rule covers the awkward case: a list of objects. There is no sensible way to join objects with a separator, so the engine stores the list as JSON text inside the cell, with its quotes doubled. Run against a test record, an empty object, an empty list, a null, a three-level nesting, and a list of objects produced exactly this:
With flattening off, the engine keeps it simpler and less useful: every nested value stays as JSON text in its cell. The same address object becomes the cell text {"city":"Austin"}, quotes doubled. Same values, far less usable as a table. Our flattening guide covers when each setting is the right call.
One more silent rule, and it happens before conversion even starts. Because JSON.parse keeps the last value when a key repeats, a record like {"code":"A1","code":"B2"} converts with only B2. The first value is gone before the converter sees the data. Rare in practice, worth knowing exactly once.
a,b,c,d.e.f,g
{},,,1,"[{""h"":1},{""h"":2}]"What survives the trip, and what does not
What survives: every leaf value, as text. Names, numbers, dates, notes, email addresses: all present in the CSV, all correct. If your question is "did I lose any information I typed", the answer is no. For a spreadsheet, an import wizard, or a quick human scan, nothing you need is missing.
What does not survive: types, first. The number 2023 and the text "2023" are identical in CSV; true and "true" are identical too. Whatever reads the CSV will guess, and guesses vary: Excel famously turns the text "007" into the number 7 and "1-2" into a date. Second, the nested shape: address.city no longer knows it was ever an object, and "newsletter; referral" no longer knows it was two tags. Third, duplicate keys: only the last value survives. Fourth, the distinction between null and an empty list: both become an empty cell, so "no value" and "a list with nothing in it" merge into one.
This creates the unflattening problem: converting back is guessing. Was "newsletter; referral" two tags or one string that happened to contain a semicolon? Was address.city ever an object, or was the key always literally "address.city"? A converter can guess, but the CSV does not remember. The rule of thumb: keep the JSON as your source of truth, and generate the CSV whenever you need the table view. Storage is cheap. Re-deriving shape is not.
Which format should you use?
Choose JSON when the data has shape or a program is the audience. Data going to or from an API, an app, or a database. Nested or ragged records where rows do not all look alike. Values whose types must survive, like prices as numbers and flags as booleans. Logs, configs, and anything code will process. If you might need the structure back later, JSON is the only safe home for it.
Choose CSV when a human or a table-shaped tool is the audience. Someone will open it in Excel or Google Sheets. You are emailing data to a non-technical colleague. The target tool expects rows and columns: BI dashboards, import wizards, mailing-list uploaders. The data is genuinely flat, and you want the smallest file: measured on the build machine, 1,000 uniform customer rows took 111,433 bytes as JSON but only 48,473 bytes as CSV, under half the size, because JSON repeats every key name in every row. For nested data the comparison breaks down, since CSV cannot hold nesting without workarounds, but for flat tables CSV wins on size every time.
The practical combo most teams land on: store and exchange JSON, export CSV on demand. Keep the rich original; generate the flat working copy whenever someone needs it. The converter on this page exists for exactly that second step, and our methods guide covers the three reliable ways to do it: the online converter, Excel Power Query, and Python.
Going between the two formats
JSON to CSV is the trip this site is built for: paste or upload your JSON on the converter at the top of this page, no signup, and the conversion runs entirely in your browser so your data never leaves your machine. For repeatable or scripted work, our conversion guide walks through the same job in Excel Power Query and in Python.
CSV to JSON is the return trip, and it comes with the honest caveat from the previous section: types have to be guessed on the way back, because the CSV never stored them. Our reverse guide covers the conversion and shows where the guesses can go wrong, so you can check them instead of trusting them.
Related guides
- How to Convert JSON to CSV: 3 Reliable Methods (2026 Guide)
- How to Flatten JSON to CSV: What the Toggle Actually Does (2026 Guide)
- How to Convert CSV to JSON: 3 Reliable Methods (2026 Guide)
- What Does Flattening a JSON Mean? The Term Explained (2026 Guide)
- What Is JSON to CSV Online? The 3 Words Explained (2026 Guide)
- What Is JSON to CSV Converter Online? Anatomy of the Tool (2026 Guide)
- Convert JSON to CSV Locally: Keep the File on Your Machine (2026 Guide)
- What Are Ways to Convert JSON to CSV Locally? 6 Methods, Compared (2026 Guide)
- Why Your CSV Opens in One Column in Excel, and How to Fix It (2026 Guide)
- Why Your CSV Shows Weird Characters in Excel, and How to Fix the Encoding (2026 Guide)
- Why Excel Drops the Leading Zeros From Your CSV Codes, and How to Keep Them (2026 Guide)
- Why Excel Changes Your CSV Dates, and How to Keep Them (2026 Guide)
- Why Saving Your CSV in Excel Changes It, and How to Keep the Original Safe (2026 Guide)
- Why Excel Won't Open Your Big CSV File, and What to Do Instead (2026 Guide)
Frequently asked questions
Is JSON the same as CSV?
No. JSON stores nested, typed data as objects and arrays; CSV stores flat tables as rows of text. They solve different problems: JSON is for structured data that programs exchange, CSV is for tables that humans open in spreadsheets. You convert between them constantly, which is why both formats refuse to die.
Can a CSV file hold nested data like JSON can?
Not natively. A CSV has rows and columns and nothing deeper, so nesting has to be flattened (an address object becomes address.city and address.state columns) or packed into a single cell as JSON text. Both workarounds lose the original shape, which is why you keep the JSON whenever the nesting matters. Our flattening guide shows exactly what the flatten toggle does to nested data.
Does converting JSON to CSV lose data?
It loses shape, not values. Every leaf value survives as text, but types collapse (numbers and booleans become text), nesting flattens into dot-notation columns, duplicate keys keep only the last value, and null and empty lists both become empty cells. For a spreadsheet or an import, nothing you need is missing. For round-tripping back to JSON, keep the original file.
Which is smaller, a JSON file or a CSV file?
For flat, uniform data, CSV is usually much smaller. Measured on the build machine: 1,000 customer rows took 111,433 bytes as JSON but only 48,473 bytes as CSV, under half the size, because JSON repeats every key name in every row. For nested data the comparison breaks down, since CSV cannot hold nesting without duplicating or serializing it. Pick by shape, not by size.
Can Excel open a JSON file?
Not directly as a spreadsheet. The reliable paths are: convert the JSON to CSV first and open that, or use Power Query (Data > Get Data > From File > From JSON), which imports JSON into Excel properly. Our file-conversion guide walks through the Power Query path step by step.
Is JSON human-readable?
Yes, it is plain text, and small pretty-printed JSON reads fine. Readability collapses with size and depth: a minified single-line export is technically readable and practically hostile. For big files, pretty-print first with a formatter, or convert to CSV and scan the table instead.
Why do APIs return JSON instead of CSV?
Because API data is rarely a flat table. Responses nest (a user has an address, which has coordinates), mix types (numbers, booleans, nulls), and vary per record, all things JSON handles and CSV cannot. CSV shines when the data is already a table and a human is the audience; JSON shines when the data has shape and a program is the audience.
Turn JSON into CSV in one tab
Now that you know both formats, convert between them here: paste JSON, download CSV. Free, no sign-up, runs entirely in your browser.
Open the JSON to CSV converter