JSON to CSV (and Back)

Two formats built for different shapes of data

JSON was designed to represent whatever shape your data actually has. An object can contain another object, which can contain an array, which can contain more objects, as deep as you need to go. A single JSON record might have a name and age sitting right next to an array of addresses, each with its own nested object of geocoordinates. Nothing about the format forces you to flatten that out. Types are explicit too: a number is a number, a boolean is true or false, and null means something specific and different from an empty string.

CSV doesn't have any of that. It's a grid: rows and columns, full stop. There's no way to express "this cell contains another table" or "this field is actually a list of three things." Every value in a CSV file is text, even if it looks like a number when you glance at it. If a JSON record has a nested array of tags, CSV has no native concept of a nested array of tags. It only has cells, and something has to decide what goes in that cell before the conversion can happen.

That mismatch is the whole story behind why converting between the two isn't just a mechanical reshuffle. Going from a nested, typed format to a flat, text-only one means making decisions the original data didn't specify. Going the other way means guessing back at structure and types that CSV never recorded in the first place. Neither direction is lossless by default, and knowing where the loss happens is most of what you need to convert cleanly.

It also helps to remember that both formats were built for a purpose, not chosen arbitrarily. JSON grew up alongside JavaScript and web APIs, where the data naturally has structure: a user object with an address, a list of order items, a settings blob three levels deep. CSV predates that world by decades. It comes out of an era when "data" meant a table in a database or a printed report, and a table is exactly what a spreadsheet was built to hold. Neither format is wrong for what it was designed for. The friction only shows up when a piece of data has to travel from one world into the other, which happens constantly, because the tools people actually use day to day don't all agree on which world they live in.

Why you'd convert JSON to CSV

The most common reason is that someone wants to open the data in Excel or Google Sheets, and neither of those tools speaks JSON natively. An API response full of nested objects is unreadable to a non-technical colleague, but a spreadsheet with columns and rows is something anyone can filter, sort, or drop into a pivot table without asking an engineer first. This is probably the single biggest use case for a json to csv converter: turning an API dump into something a product manager or analyst can actually work with.

There's also a whole category of downstream tools that only accept flat tabular input. Bulk-import forms for CRMs, ad platforms, and email tools almost always want CSV, not JSON, even when the underlying data started life as a JSON export from some other system. Data pipelines built around traditional databases or BI tools frequently expect a flat file too, since that's the format their ingestion step was written for a decade before JSON became the default API response format.

And sometimes it's simply about sharing. A CSV attached to an email opens in whatever spreadsheet app the recipient already has installed. A JSON file attached to an email gets opened in a text editor and stared at blankly. If you need a json array to csv online conversion just to send someone a readable file, that's a completely reasonable reason to reach for a converter rather than write a script for a one-off task.

There's a quieter reason too: CSV is a decent audit format. Open a CSV in a spreadsheet and you can eyeball two thousand rows in a few seconds, scanning for a blank cell or an obviously wrong value in a way that's much harder scrolling through the same records as nested JSON. When you're debugging a data export or sanity-checking what an API actually returned, flattening it into a grid first is often the fastest way to spot the row that's broken.

Why you'd convert CSV to JSON, and what nesting actually breaks

The reverse direction shows up just as often. You've got a spreadsheet of customer data, or a CSV export from some legacy system, and you need to feed it into an API or an app that expects JSON. Most web APIs accept JSON bodies, not CSV uploads, so if your source data starts life as a spreadsheet, converting csv to json is usually the first real step in getting it anywhere useful. Config files are another common target. Plenty of tools read JSON config, and hand-writing a JSON config from a spreadsheet someone else maintains is a good way to introduce typos that a converter avoids.

Where JSON to CSV actually gets tricky is the nested case, because there's no single correct answer for what to do with a nested object or array once you hit a flat grid. One common approach flattens nested keys with dot notation, so {"address":{"city":"Reno"}} becomes a column literally named address.city. That works fine for a fixed, shallow shape. It gets messier with arrays: if one record has three tags and another has one, do you get three separate columns (tags.0, tags.1, tags.2) with blank cells for the records that only had one, or do you join the array into a single delimited string like "red;blue;green" inside one cell? Different tools pick different answers, and a spreadsheet built by one convention won't parse cleanly by the other. I've seen a support export where one tool's "tags" column meant a semicolon-joined string and a second tool's importer expected repeated numbered columns instead, and the two just silently disagreed with each other until someone diffed the row counts.

The other common approach, and the one GlaeKit's converter uses, is to leave nested values alone and drop the raw JSON string into a single cell. It's less pretty to look at in a spreadsheet, but it's honest about what happened: nothing was silently reshaped or guessed at, and if you need the nested data back out, it's still sitting there intact as a string you can re-parse. Which approach is "right" really depends on what happens to the file next. If a human is going to skim it in Sheets, dot-notation columns read better. If the file is a transport step before the data goes back into code, keeping nested structures as JSON strings avoids inventing a flattening scheme nobody agreed on. There's no converter setting that gets this right for every case, because the "right" answer depends on who or what reads the output next, not on the data itself.

CSV's own ambiguities, and how to keep a round-trip clean

Even setting nesting aside, CSV has surprisingly little standardization for something so old and widely used. A comma inside a value has to be distinguished from a comma separating fields, which is why fields containing commas get wrapped in quotes, but not every tool agrees on when to add those quotes preemptively versus only when necessary. A newline inside a field (someone's multi-line address, say) is legal inside a quoted field per RFC 4180, but plenty of naive line-by-line parsers will happily split that record in half because they never learned to look for an open quote before treating every newline as a row boundary.

One that's bitten me more than once: Excel on Windows writes CSV exports with a UTF-8 byte-order-mark at the very start of the file. Most tools swallow it invisibly, but a parser that isn't expecting it reads the first header as "name" instead of "name", and every lookup against the literal string "name" quietly fails with no error message at all. It just looks like the column doesn't exist. It's the kind of bug that costs an hour before you think to open the file in a hex viewer, and it's a good reminder that "CSV" is really a family of loosely compatible dialects rather than one strict format.

There's also no standard way to represent a null. Some tools leave the cell empty, some write the literal text null, and once you convert csv to json, an empty cell and a missing key can mean different things depending on which side is doing the interpreting. Quoting conventions drift between tools too: some quote every field regardless of content, others only quote fields that need it, and a parser tuned for one style can misread the other if it's making assumptions instead of actually tracking quote state character by character.

A clean round-trip usually comes down to a few habits. Pick one nesting convention and stay consistent with it across every export from a given source, rather than switching between dot notation and raw JSON strings file to file. Quote every field that might ever contain a comma, not only the ones that currently do, since "currently doesn't have a comma" is a property of today's data, not a guarantee about tomorrow's. Decide up front how you're representing empty versus null so the next tool in the chain doesn't have to guess. None of this is exotic; it's just detail that's easy to skip until a file with three thousand rows breaks on row 1,847 because one address happened to have a comma in it. Testing the round-trip on a handful of edge-case rows before trusting it on the full dataset catches most of this early, and it's a lot cheaper than debugging a partial import after the fact.

Try it

GlaeKit's JSON to CSV / CSV to JSON converter runs entirely in your browser, handles quoted fields correctly in both directions, and doesn't upload your data anywhere.

Frequently asked questions