Convert JSON to CSV or a Spreadsheet
Turn a JSON array into a CSV file you can open in Excel or Sheets — processed locally in your browser.
Drop your file here or click to browse
JSON files (.json)
Your data stays on your device
Nothing to delete afterwards
Safe for raw API responses
Works in every modern browser
How it works
- 1
Paste or drop your JSON
An array of objects works directly; paste the text or drop a .json file on the page.
- 2
Check the header row
Confirm the columns match what you expected before you take the file into a spreadsheet.
- 3
Download the CSV
Open it in Excel, Google Sheets, or Numbers, or feed it to a system that imports CSV.
Why use this tool
Nesting is flattened
Objects inside objects become dotted column names instead of being dropped or dumped as raw text.
One header for ragged data
Records that do not share the same keys still line up, because the header is the union of every key seen.
Opens cleanly in Excel
Quoting and escaping follow the rules spreadsheets actually implement, so columns land where they belong.
Nothing is uploaded
The parsing happens in your browser — an API response full of customer records never reaches a server.
No record limit
Your device memory is the only ceiling, not a free-tier row cap.
Free, no account
No signup, no watermark, no cap on how many files you convert.
A tree has to become a rectangle, and you choose where to cut it
This is the whole difficulty of the direction. JSON is a tree: objects inside objects, arrays inside those. CSV is a rectangle: a fixed set of columns, one record per line, no nesting available at all. So a converter cannot simply translate — it has to flatten, and flattening means deciding what counts as a row. For a plain array of flat objects the answer is obvious, one object per line. For anything deeper it is a real choice. An order containing a list of line items can become one row per order with the items crushed into a single cell, or one row per line item with the order details repeated down every row. Neither is wrong; they answer different questions. Know which one your destination expects before you convert, because the wrong choice produces a file that looks fine and counts everything twice.
JSON records do not have to agree, and CSV insists they do
An array of JSON objects can be ragged. The first record has seven keys, the fourth has nine, the ninth is missing one the others all carry — this is perfectly valid JSON, and API responses produce it constantly because optional fields are simply omitted rather than set to null. A CSV has one header row that governs every line beneath it, so the column set has to be the union of every key that appears anywhere, and records missing a key get an empty cell. That is the only workable answer, but it hides something: an empty cell cannot tell you whether the key was absent, present but null, or present and set to an empty string. All three collapse into nothing. If that distinction matters to whatever reads the file next, it has to be preserved in the JSON before conversion, because CSV has no way to carry it.
Types are lost on the way out, and that is usually fine
Going into JSON, the hard question is which strings should become numbers. Coming out, the question disappears — CSV has no types, so `42`, `true`, and `null` all become plain characters and their meaning is handed to whatever reads the file. Mostly this is harmless, because the reader is a spreadsheet and a person. It becomes visible in two places. Boolean fields arrive as the literal text `true` and `false`, which sorts and filters differently from a checkbox and may need converting if a colleague plans to work with them. And null becomes an empty cell, which — as above — is indistinguishable from a missing field. Neither is a defect in the conversion; both are worth knowing before someone builds a formula on top of the result.
Why a text field can turn into a formula
This is the one genuine safety issue in this direction, and it exists because JSON strings often carry text that people typed. When a spreadsheet opens a CSV, it treats any cell starting with `=`, `+`, `-`, or `@` as a formula rather than as text. A product description beginning with a minus sign, a note field starting with `@name`, an address line that opens with a plus — each becomes something the spreadsheet tries to evaluate, and at best you get an error in the cell instead of your data. In the worst case a deliberately crafted value becomes an executable formula in someone else's workbook, which is why this is tracked as CSV injection rather than as a formatting quirk. If the JSON came from a form real users filled in, look down those columns after opening rather than assuming the text arrived as text.
The destination is a person, and that is the point
This conversion runs in a specific direction for a specific reason. JSON goes to programs; CSV goes to people, and to the systems people already run. An API response becomes a sheet a colleague can sort and filter. An export from a tool becomes a file the finance team can pivot. A list of records becomes something you can hand to someone who will never open a code editor. That is why the target is CSV rather than keeping the data as-is, and it is why the header row matters more than the byte size — the point is legibility. If the audience is a program rather than a person, you probably want the reverse direction, or no conversion at all. And if the file is going straight into Excel and staying there, going to a real workbook skips the encoding and separator questions entirely.
Why converting locally matters for this kind of file
JSON that people convert to CSV is nearly always something a system produced: an API response, a database export, a webhook payload, a report from an internal tool. Those payloads carry more than the fields you were looking at. Internal identifiers, email addresses, timestamps, and sometimes an access token or a session identifier sit in keys you never scrolled to, because you only came for three columns. A hosted converter receives all of it. This tool runs entirely in your browser: the text is parsed on the page and the CSV is written back without a single network request carrying the data, which you can confirm in the Network tab of your developer tools. When the input is a raw API response, that difference is worth more than the two minutes it saves.
Common mistakes to avoid
- Converting nested data without deciding what a row is. An order with line items can become one row per order or one row per item — pick deliberately, because the wrong choice produces a file that looks correct and double-counts totals.
- Trusting an empty cell to mean something specific. A blank could be a missing key, a null, or an empty string; if the distinction matters, preserve it in the JSON before converting, because CSV cannot carry it.
- Opening the result without checking cells that start with `=`, `+`, `-`, or `@`. Spreadsheets treat those as formulas, so user-typed text can arrive as an error or, worse, as something executable.
- Assuming every record has the same keys. API responses omit optional fields rather than nulling them, so the header has to be the union of all keys — verify the column count is what you expected.
- Pasting a raw API response into an online converter. Those payloads usually carry identifiers, emails, and sometimes tokens in fields you never scrolled to; convert locally instead.
How it compares
| Aspect | This tool | Online converters | A script of your own |
|---|---|---|---|
| Data sent to a server | Never | Usually yes | No |
| Setup required | None | None | Runtime and dependencies |
| Nesting flattened | Yes, dotted columns | Varies | Whatever you write |
| Record limit | Device memory only | Often capped | None |
| Account or signup | Not needed | Often required | Not needed |
| Price | Free | Free / paid tiers | Your time |
Features
Dotted columns for nesting
A nested `address` object becomes `address.city` and `address.postcode` rather than a stringified blob.
Union header
Every key found across the records appears once, so a field missing from some rows still gets a column.
RFC-compliant quoting
Values containing commas, quotes, or line breaks are quoted and escaped so the row structure survives.
UTF-8 output
Accented, Arabic, Turkish, and other non-ASCII text is written out unchanged.
Handles large arrays
Tens of thousands of records convert without an upload queue.
Nothing to install
No download, no runtime, no dependencies — it runs on the web page.
Arabic and RTL ready
Full interface in eight languages, including right-to-left Arabic.
Secure by default
Served over HTTPS, with no file tracking and no third-party upload.
Works offline once loaded
The page keeps working after the tab has loaded, because the conversion is local.
Who uses it
Developers
Turning an API response into a sheet a non-technical colleague can actually read.
Data analysts
Getting a JSON export into a shape that pivots and filters without writing a parser first.
Support teams
Converting an exported ticket or log payload into something sortable in a spreadsheet.
Operations staff
Handing a system export to finance or management in a format they already use daily.
Frequently Asked Questions
No. The conversion runs entirely in your browser — your data is never uploaded, stored, or shared.
Yes. Every row and column is converted faithfully; the structure is preserved.
Yes — completely free, with no account, no watermark, and no limit on how many files you convert.