How to Make CSV from JSON: 7 Decisions That Turn Raw Data into a Working File (2026 Guide)

Making is not the same as converting

People say \"make a CSV\" and \"convert JSON to CSV\" as if they were the same thing. They are not. Conversion is mechanical: the same JSON always produces the same CSV from the same settings. Making is authorial: the file you hand to a colleague, import into a database, or feed to an analysis tool has to survive environments you do not control — Excel in another country, a database loader with strict rules, a coworker who opens everything by double-clicking.

The gap between \"converted\" and \"made\" is seven decisions. Skip them and the file still converts; it just breaks somewhere downstream, at the worst possible moment. The good news: each decision takes seconds, and once you understand what it is, you will never unsee it. Every example below was run through this site's real conversion engine — the same JavaScript that runs when you press Convert — so the outputs shown are what you will actually get.

Decision 1: flatten the tree before you author the grid

You cannot author columns out of nested JSON. A CSV is a grid — rows and columns, every cell a single flat value — and nested objects have no column to live in. So the first decision is to flatten: nested objects become dot-notation columns (customer becomes customer.name and customer.city), lists of plain values join into one cell, and nulls become empty cells. This is the mechanical step, and it is the one the converter does for you with its flattening toggle.

Why do it first? Because every later decision — header names, delimiters, quoting — operates on the flattened result. If you rename headers before flattening, you are naming columns that do not exist yet. The engine here flattens by default with the option name flattenNested, so in practice this decision is: leave it on, glance at the preview, and confirm the column names are what you expect.

Decision 2: name your columns like a contract

Header row names are a contract with every tool that will ever touch the file. Bad header names are the quietest way to make a bad CSV: they never fail at conversion time, they fail in the database import three weeks later. Four rules cover nearly everything:

No spaces in header names. \"order id\" is readable to you and a bug report to a SQL loader; use orderId or order_id instead. The flattening engine already produces space-free dotted names (customer.name), so only your top-level keys need attention.
No duplicate names. Two identical headers mean the second column silently overwrites the first in many importers. If your JSON has both \"user.name\" as a literal key and a nested user: { name }, flattening merges them into one column — the nested value wins and the other is lost. Rename before converting if both values matter.
No leading digits. Column names like \"2024-sales\" break in many SQL dialects and some BI tools. Prefer sales_2024.
Stable and spelled out. A header is an API: abbreviating \"qty\" is fine, but \"q\" will confuse someone in six months. Pick full words once and reuse them across files.

One thing not to fear: non-ASCII header names. If your columns are product_name and Japanese labels like \"商品名\", UTF-8 carries them fine (Decision 6 covers encoding). The engine writes header cells through the same quoting rules as data cells, so even a header containing a comma or quote is escaped correctly — we verified the escaping logic in the source; quoting is applied per cell, headers included.

Decision 3: choose the delimiter on purpose

The comma is the default delimiter, and for most files it is the right one. But the delimiter is not a formality — it is the character the entire file is parsed by. The converter offers comma, semicolon, tab, pipe, and custom, and here is when each earns its place:

Comma: the default. Use it unless you have a reason not to. Every tool reads it.
Semicolon: when your data is full of commas. European exports use this heavily — not coincidentally, because many European locales use the comma as the decimal separator, so a comma-delimited file would be ambiguous. If your text fields are full of commas, the semicolon keeps cells readable without relying on quoting.
Tab: when humans will read the raw file. Tab-separated values paste straight into spreadsheets and stay readable in a text editor. Useful for copy-paste workflows.
Pipe: when your text contains commas, quotes, AND semicolons — log messages, addresses, prose. The pipe is rare inside natural text, so it rarely collides.

The honest catch: quoting exists precisely to make the delimiter choice survivable. When a cell contains the delimiter, the engine wraps it in quotes automatically (Decision 4), so a comma-heavy address in a comma-delimited file still parses. The delimiter choice is about readability and the habits of your audience, not about correctness — correctness is the quoting engine's job. One real warning, though: if you pick semicolon for an audience in the US or UK, tell them — their Excel may default to expecting commas and open your file as one long column.

Decision 4: let quoting stay automatic

Quoting is the most misunderstood part of CSV. The rule is simple: a cell that contains the delimiter, a quote character, or a line break must be wrapped in double quotes, and any quote inside it must be doubled. Here is what the engine actually produces — verified, not illustrated:

Quoting in action (verified against the real engine)

name,city,qty
"Say ""hi"", friend",Oslo,3

Read that carefully: the cell Say \"hi\", friend became \"Say \"\"hi\"\", friend\" — wrapped in quotes because it contains a comma, and its inner quotes doubled. That is the correct, standards-conforming output, and every real spreadsheet program parses it back to exactly the original text.

Decision 4: let quoting stay automatic (continued)

Switch the delimiter to semicolon and watch quoting adapt:

Same data, semicolon delimiter (verified)

name;city;qty
"Say ""hi"", friend";Oslo;3

The comma no longer triggers wrapping, but the quote character still does — the engine quotes per the actual delimiter in use, not per a fixed idea of what is \"special.\" This per-delimiter awareness is what \"automatic\" means, and it is the setting you should leave alone. The engine also offers always and never quote modes; never is a footgun, and here is the proof:

Decision 4: let quoting stay automatic (continued)

quoteMode \"never\" — the footgun (verified)

note,code
line1
line2,007

With quoting disabled, a cell containing a real line break stays raw — and that line break now looks like a row boundary to every parser on Earth. Your 2-row file reads as 3 rows, one of them garbage. Quotes still get doubled (the engine does that unconditionally), but nothing is wrapped. Use \"never\" only when a downstream system explicitly demands unquoted output and you have verified none of your cells contain delimiters, quotes, or line breaks. In every other case: automatic.

Decision 5: make values text the way you want them seen

JSON has types — numbers, booleans, nulls. CSV has exactly one type: text. The moment of conversion is when every value becomes its final text form, and this is the decision most people never consciously make. Three value shapes deserve your attention:

First, leading zeros. A JSON string like \"007\" stays 007 in the CSV — we verified it, unquoted, exactly as typed. But opening that file in Excel will still display 7, because Excel re-interprets cells on open. The CSV is correct; the viewer is opinionated. If leading zeros must survive Excel, the fix is on the receiving side (import as text), not in the file — know this before you blame the converter.

Second, dates. JSON has no date type, so your \"dates\" are strings like 2026-10-14 or timestamps like 1697000000. Whatever shape you convert is the shape the CSV keeps, so choose the human-facing one before exporting: ISO 2026-10-14 sorts correctly as text; 10/14/2026 does not, and will be misread by half the world. Make the decision in the JSON, not after the CSV exists.

Third, decimals and booleans. A number like 19.99000001 becomes exactly that text; booleans become true/false. If your source data has float noise, round it before conversion — CSV will not round for you.

Decision 6: choose UTF-8 deliberately — and know the BOM question

Encoding is the decision nobody makes until mojibake forces it. UTF-8 is the answer in 2026: it carries every language, and every modern tool reads it. The subtlety is the BOM — the invisible byte-order mark some Windows tools want at the start of the file.

Here is the honest fact about this site's converter: the download is plain UTF-8, no BOM — we read the download code, which creates a text/csv Blob with charset=utf-8 and no leading mark. That is correct for web uploads, databases, Google Sheets, and Python. The one place it bites: double-clicking the file in some Windows Excel versions, which may guess the wrong encoding and mangle non-ASCII characters.

The fix is not to demand a BOM from the converter — it is a 20-second import: in Excel, Data → From Text/CSV → choose 65001 (UTF-8) in the encoding dropdown. Your characters come out perfect and the file itself stays clean for every other tool. Decide your encoding once per workflow and document it next to the file; encoding surprises are always a communication failure, never a data failure.

Decision 7: validate the finished file before it leaves you

Making ends with a check, and it takes under a minute. Four steps:

Open it in a text editor first, not a spreadsheet. A text editor shows you the file; a spreadsheet shows you its interpretation. Verify the header row, the delimiter, and that quoted cells look sane.
Count the rows. The engine reports row and column counts in its stats — compare them to your JSON array length. A mismatch means a parsing surprise (usually an unquoted line break in quoteMode \"never\", or malformed input JSON).
Re-import it. Paste the CSV back or open it in the tool you are sending it to. If it opens correctly there, it will open correctly for the recipient.
Check the edges: first row, last row, and one row with the weirdest characters. Corruption clusters at boundaries.

This checklist is also the answer to \"why does my CSV look broken\": in our experience it is the viewer or the import settings nine times out of ten, and the file itself the tenth. The text-editor-first habit is what separates the two in seconds.

The 60-second recipe, all seven decisions in

Paste or upload your JSON into the converter. Leave flattening on and glance at the column preview — those dotted names are your headers, so rename any offending keys in the source first. Keep the comma delimiter unless your text is comma-heavy (then semicolon). Leave quoting automatic. Make dates and numbers look the way you want them seen as plain text before you convert. Download the UTF-8 file, open it once in a text editor, re-import it where it is going. Done — a made file, not merely a converted one.

Open the free JSON to CSV converter

Related guides

Frequently asked questions

How do I make a CSV file from JSON?

Paste or upload your JSON into a converter, flatten nested data into columns, review the header names and delimiter, then download. The full checklist: flatten first, name columns without spaces, keep the comma delimiter unless your data is comma-heavy, leave quoting automatic, format dates and numbers as the text you want to see, download as UTF-8, and re-import the file once to validate it.

What is the best delimiter for a CSV made from JSON?

Comma is the default and the right choice for most files. Use semicolon when your text fields are full of commas (common in European exports, where the comma is also the decimal separator), tab for copy-paste readability, and pipe when text contains commas, quotes, and semicolons. Correct quoting makes any of these parse safely — the choice is about your audience's habits, not correctness.

How should I name CSV columns made from JSON?

Treat header names as a contract: no spaces (order_id, not \"order id\"), no duplicates, no leading digits (sales_2024, not 2024-sales), and full words instead of cryptic abbreviations. Flattened nested keys already come out as space-free dotted names like customer.name — only your top-level keys usually need attention.

Why does my CSV open wrong in Excel after making it from JSON?

Nine times out of ten the file is fine and the viewer is the problem. Common causes: Excel guessing the wrong delimiter (a semicolon file opened as comma), wrong encoding guess on non-ASCII text (re-import via Data → From Text/CSV with 65001 UTF-8), or Excel re-interpreting cells (stripping leading zeros like 007, or reformatting dates). Open the file in a text editor first — if it looks right there, the file is right.

Do I need quotes around every cell in a CSV?

No — automatic (as-needed) quoting is correct and sufficient: cells containing the delimiter, quotes, or line breaks get wrapped in double quotes, with inner quotes doubled. \"Always\" adds noise, and \"never\" is dangerous: an unquoted line break inside a cell looks like a row boundary to every parser and silently corrupts your row count.

Should my CSV from JSON have a BOM?

Usually not. A UTF-8 file without a BOM works everywhere: databases, web uploads, Google Sheets, Python. Some Windows Excel versions misread BOM-less files on double-click — the fix is a proper import (Data → From Text/CSV, encoding 65001) rather than adding a BOM, which can confuse other tools. This site's converter downloads plain UTF-8 with no BOM.

How do I check that my generated CSV is correct?

Four quick steps: open it in a text editor (not a spreadsheet) to see the actual file, compare the row count against your JSON array length, re-import it into the tool you are sending it to, and inspect the first row, last row, and the row with the strangest characters. Corruption clusters at boundaries — if the edges are right, the file is right.

Make your CSV now — flattening, quoting, and headers handled

Paste JSON or upload a file: nested data flattens to clean columns, delimiters and quoting are automatic, and the download is plain UTF-8. Free, no sign-up, runs entirely in your browser.

Open the JSON to CSV converter

All guides