Half of my job on any SaaS product is getting data out of the system and into the hands of someone who does not write code. A founder wants the month's signups in a spreadsheet. A support lead wants to sort tickets in Excel. An accountant wants the orders as a .csv they can pivot. The data lives as JSON, because that is what the API returns, and every single time the task is the same: turn this array of objects into columns and rows a human can open. I got tired of writing throwaway scripts for it, which is exactly why the Toolz JSON to CSV converter exists. This guide is how I think about that conversion, including the parts that trip people up.
TL;DR: A JSON to CSV converter takes an array of objects and writes it as comma-separated rows, one column per property, so a spreadsheet can open it. The hard parts are records with different fields, nested objects, and values that contain commas. A good converter builds the header from the union of all keys, can flatten nested objects into dot-notation columns, and escapes fields per RFC 4180. The Toolz tool does all three client-side, and lets you pick the delimiter and CRLF line endings so the file opens cleanly in Excel.
I build on Laravel and React, so JSON is my native format and CSV is the lingua franca I export to. The interesting engineering is not the happy path where every object has the same three keys; it is the messy reality of production data, and that is where most converters quietly do the wrong thing.
What is a JSON to CSV converter?
A JSON to CSV converter reads a JSON array of objects and produces a table: the property names become the header row, and each object becomes one data row beneath it. Paste the response from an API endpoint, a database query, or an exported document, and you get a file you can open directly in Excel, Google Sheets, or Numbers. It is the bridge between the format machines exchange and the format people actually work in.
The ideal input is an array of flat objects that all share the same keys, because that maps perfectly onto a rectangular table. Real data is rarely that tidy. Objects go missing a field, values nest two levels deep, and some entries are arrays rather than scalars. The whole value of a dedicated converter is that it has a defined, sensible answer for each of those cases instead of throwing an error or dropping data. If your JSON is minified or you just want to inspect it first, run it through the JSON formatter to pretty-print and validate it before you convert.
How does it handle objects with different fields?
This is the first thing that breaks naive converters, and it is worth understanding because production JSON almost never has uniform objects. Suppose your array has one object with id, name, and email, and the next with id, name, and phone. What columns should the CSV have?
The correct answer is the union of every key across all objects, kept in the order each key first appears. So the header becomes id, name, email, phone, and any object missing one of those keys simply gets an empty cell in that column. Nothing is dropped, and the table stays rectangular. A lazy converter that only reads the keys of the first object would silently lose the phone column entirely, taking every phone number with it. The Toolz converter scans all rows to build the header, so uneven records still line up into a clean, complete table. This one behavior is the difference between an export you can trust and one that quietly omits data nobody notices until it is too late.
What about nested objects and arrays?
JSON is a tree; CSV is a grid. Flattening one into the other is the second place converters diverge, and the right choice depends on what you plan to do with the file.
For nested objects you have two reasonable options, and the tool supports both. With flattening on, a nested object is expanded into dot-notation columns, so { "address": { "city": "Paris", "zip": "75001" } } becomes an address.city column and an address.zip column. That is what you want when the nested fields are real data a person will read and sort. With flattening off, the whole nested object is written as a compact JSON string inside a single cell, which is better when the structure is opaque and you just need to preserve it verbatim.
Arrays get their own choice, because there is no single right way to squeeze a list into one cell. You can store the array as JSON, keeping ["a","b"] intact so it round-trips perfectly, or you can join the elements with a separator to get the more human-readable a; b. I use JSON when the file will be read back by a program and the join format when a person is the audience and readability wins. The table below summarizes the decisions.
| Input shape | Flatten ON | Flatten OFF |
|---|---|---|
{"user":{"name":"Ada"}} |
column user.name = Ada |
column user = {"name":"Ada"} |
{"tags":["x","y"]} (arrays as JSON) |
column tags = ["x","y"] |
column tags = ["x","y"] |
{"tags":["x","y"]} (arrays joined) |
column tags = x; y |
column tags = x; y |
| object missing a key | empty cell in that column | empty cell in that column |
Why do commas and quotes need escaping?
This is the rule that, ignored, produces a file that looks fine until someone opens it and the columns are all wrong. CSV uses the comma to separate fields, so what happens when a value contains a comma? Or a double quote? Or a line break from a multi-line note?
RFC 4180, the closest thing CSV has to a standard, answers this precisely: any field containing the delimiter, a double quote, or a line break must be wrapped in double quotes, and any double quote inside that field must be doubled. So the value Baker, Smith & Co. is written as "Baker, Smith & Co.", and She said "hi" becomes "She said ""hi""". The Toolz converter applies these rules to every cell automatically, which is why an address, a price with a thousands separator, or a free-text comment survives the trip into a spreadsheet as a single, intact field instead of shattering into extra columns.
How do I make the file open cleanly in Excel?
You would think a CSV is a CSV, but Excel on Windows is fussy about one thing that catches people out: line endings. Getting this right is the difference between a file that opens perfectly and one where rows appear merged or split.
Excel on Windows expects each row to end with a carriage return plus a line feed, the CRLF pair. If you hand it a file with Unix-style LF line endings, it can misread where rows break, especially when a quoted field contains its own newline. The converter lets you choose LF or CRLF, so pick CRLF when the audience is Excel on Windows and LF for most other tools and for Google Sheets, which is happy with either. You can also choose the delimiter: comma is the default, but semicolon is common in European locales where the comma is the decimal separator, and tab or pipe are handy when your data itself is full of commas. Matching the delimiter and line ending to the destination is a five-second choice that saves a support ticket later.
Is it safe to convert sensitive JSON online?
Yes, because none of it leaves your browser. Every part of the conversion, from parsing the JSON to escaping each field to joining the rows, runs in JavaScript on your own machine. There is no upload and no server, so nothing is transmitted, logged, or stored. Open the network tab and click Convert: you will see no request go out, and once the page has loaded the tool works with the internet disconnected.
This is not a minor detail for JSON specifically, because JSON is what API responses and internal systems speak. The array you are converting might hold user records, order data, access tokens, or anything else your backend returns. A converter that ships your payload to a remote server turns a private response into someone else's log line. Doing the work client-side means the data stays exactly where it started. It is the default for every tool on toolz.dev, and if you want the fuller case for why that architecture matters, I laid it out in the data privacy guide for online tools.
Where does this fit in a real pipeline?
On its own the converter is one step, but it is usually the last hop of a longer flow, and it pairs naturally with a handful of other tools. The most common round trip in my week is: export JSON from an API, edit or filter it, convert to CSV, and hand it to someone who lives in spreadsheets. When they send it back with changes, I convert the other direction with the CSV to JSON converter, which parses the file per RFC 4180 and infers types so I get clean objects again. The two tools are deliberate mirrors of each other, which is why they cross-link.
Before converting, I often want to see the data as a grid to sanity-check it, and the CSV viewer renders CSV as a sortable table so I can confirm the export looks right. And when the destination is not a spreadsheet at all but another system that speaks XML, the XML to JSON converter and its counterparts cover that leg. Because every one of these runs locally, you can chain them on the same private file without a single upload. If you are putting together a set of go-to tools for this kind of data wrangling, my web developer toolkit guide covers how I think about assembling one.
Frequently asked questions
How do I convert JSON to CSV?
Open the JSON to CSV converter, paste a JSON array of objects into the input box, and click Convert. The object keys become the header row and each object becomes a data row, then you can copy the CSV or download it as a .csv file to open in Excel or Google Sheets. All processing happens in your browser, so nothing is uploaded.
What JSON structure does the converter expect?
An array of objects is ideal, where each object becomes one row. A single object is also accepted and becomes a one-row file. Values that are not objects are placed under a value column so nothing is lost, and the tool warns you when that happens.
How does it handle objects with different fields? The header is the union of every key found across all objects, kept in the order each key first appears. An object missing one of those keys simply gets an empty cell in that column, so uneven records still produce a clean, complete table with no data dropped.
How are nested objects and arrays handled?
With flattening on, a nested object expands into dot-notation columns like address.city; with it off, the object is written as a JSON string in one cell. Arrays can be stored as JSON to preserve them exactly, or joined with a separator for a more readable column. You choose per conversion.
Why should I use CRLF line endings for Excel? Microsoft Excel on Windows expects carriage-return plus line-feed at the end of each row. Choosing CRLF avoids rows being merged or misread when you open the file. For most other tools and for Google Sheets, LF works fine.
Are commas and quotes inside values escaped correctly? Yes. Following RFC 4180, any field containing the delimiter, a double quote, or a line break is wrapped in double quotes, and internal quotes are doubled. This keeps addresses, descriptions, and other free text as a single valid field instead of splitting across columns.
Is it safe to convert sensitive JSON? Yes. The conversion runs entirely in JavaScript in your browser, no network request carries your data, nothing is logged or stored, and it works offline once loaded. JSON containing API keys, user records, or internal identifiers never leaves your machine.
Can I convert the CSV back to JSON? Yes. The CSV to JSON converter reverses the process, parsing the comma-separated file back into a JSON array of objects with type inference. Round-tripping lets you move data between spreadsheets and APIs without rewriting it by hand.
