The JSON to CSV converter above takes a JSON array of objects β the shape almost every API returns β and turns it into a flat CSV file you can open in Excel, Google Sheets, or hand to a data analyst who has never heard of a nested object. It runs entirely in your browser: nothing you paste is ever sent to a server.
At Arb Digital we build this kind of small, sharp utility all the time for client dashboards and data pipelines, so we packaged the logic into a free, public tool rather than keeping it buried in an internal script.
What This JSON to CSV Converter Does
You paste a JSON array β a list of objects wrapped in square brackets, each object representing one "row" of data β and the tool produces a CSV (comma-separated values) table. It automatically discovers every key used across all the objects, flattens any nested objects into dot-notation columns, and quotes any field that needs it so the file opens correctly in spreadsheet software. The hero panel tells you exactly how many rows and columns you ended up with, so you can sanity-check the result before you download or paste it anywhere.
How to Use It
- Paste your JSON. It must be an array of objects, like
[{"a":1},{"a":2}]. A single object or a non-array value will show a clear error instead of silently failing. - Click Convert to CSV. The tool parses the JSON, builds the header row, and flattens each object into a CSV row.
- Check the stats. "N rows Γ M columns" tells you the shape of the result at a glance β useful for catching a typo that accidentally added an extra column.
- Copy the output. Paste it straight into a spreadsheet, save it as a
.csvfile, or pipe it into another tool.
Why JSON to CSV Is Harder Than It Looks
JSON is hierarchical by nature β objects can contain other objects, arrays can contain objects, and different items in the same array don't have to share the same shape. CSV, on the other hand, is strictly flat: rows and columns, nothing nested. That mismatch is the entire reason this conversion needs real logic instead of a one-line find-and-replace.
The real work happens in two places. First, flattening: when an object contains a nested object, like {"address": {"city": "Austin", "state": "TX"}}, the converter needs to decide how to represent it as columns. The common, spreadsheet-friendly convention β and the one this tool uses β is dot-notation: the nested keys become address.city and address.state. It only flattens one level deep, which covers the vast majority of real API responses without making column names unreadable. Arrays inside a field (like a list of tags) are joined into a single semicolon-separated string, since CSV cells can't hold a list.
Second, quoting. Per the RFC 4180 specification, if a field's value contains a comma, a double quote, or a line break, the whole field must be wrapped in double quotes, and any double quote inside it must be doubled (" becomes ""). Skip this step and a name like Reyes, Marco or an email list separated by commas will silently split into extra columns, corrupting every row after it. The "Quoted fields" counter in the result panel exists specifically so you can confirm the converter actually caught those cases in your data.
Why the Header Row Needs a Union of Keys
Real-world JSON is rarely perfectly uniform. One customer record might have a phone field and the next one might not, because the field was optional in the source system. If you only looked at the first object to decide your CSV columns, you'd silently drop data from every other record that has fields the first one lacks β a very easy, very common bug in hand-rolled converters.
This tool avoids that by scanning every object in the array first, collecting the full set β the union β of keys that appear anywhere, and using that as the header row. Objects that don't have a particular key simply get an empty cell in that column, rather than the whole row shifting out of alignment. This is the same reason the "columns" count in the result panel can end up higher than what any single object in your JSON contains: it reflects the union, not just one row.
Arrays, Nulls, and Other Edge Cases
- Nested arrays of objects (an object inside an array inside a field) are converted to a compact JSON string in the cell, since a second level of flattening would make the column names unmanageable.
- Null values become an empty cell, matching how most spreadsheet tools already treat blanks.
- Booleans and numbers are written as their literal text (
true,42) β no automatic conversion to Excel-style TRUE/FALSE. - Empty arrays β pasting
[]β produce a valid but empty CSV (zero rows), which is correct behavior, not an error.
A Worked Example: From API Response to Spreadsheet
Say your product's API returns a customer export as JSON, and you need to hand it to a colleague who only works in spreadsheets. A typical record might look like {"id": 101, "name": "Ava Chen", "plan": {"tier": "pro", "renews": "2026-11-01"}, "seats": [3, 7, 12]}. Run that through the converter and the header row becomes id, name, plan.tier, plan.renews, seats, with the seats array collapsed to 3;7;12 in a single cell. That's the difference between a document your colleague can open in one click and a JSON blob they'd have to ask an engineer to explain.
Now imagine the export has 500 customers, and 40 of them are missing the plan field entirely because they're on a legacy free tier with no plan object. Without a union-of-keys approach, a naive converter that just reads the first record's keys would produce a CSV with no plan.tier column at all β silently losing that data for the 460 customers who do have it. Because this tool scans every record first, the column still appears, and the 40 legacy customers simply show blank cells for it. That one design decision is the difference between an export you can trust and one you have to double-check by hand.
CSV Dialects and Spreadsheet Compatibility
Not every program that claims to read "CSV" agrees on the details, which is exactly why RFC 4180 exists β to give tool authors a common baseline. This converter follows that baseline closely: comma-separated fields, CRLF (\r\n) line endings, and double-quote escaping for special characters. That combination opens cleanly in Excel, Google Sheets, Numbers, and virtually every database's bulk-import tool.
Where dialects diverge is usually the delimiter itself. Some European locales default to a semicolon because the comma is already used as the decimal separator in numbers like 1.234,56. If you're going to open the output in a spreadsheet configured for one of those locales and the columns look merged into one, the fix is usually in the import settings (choosing "comma" as the delimiter explicitly) rather than in the file itself β the CSV this tool produces is standards-compliant either way.
It's also worth knowing what CSV deliberately gives up. There's no way to represent a data type in a plain CSV cell β a number, a date string, and a numeric-looking ZIP code like 02134 all just look like text once they're in a cell, and it's up to whatever reads the file next to interpret them. If your workflow depends on preserving types precisely (a boolean staying a boolean, a number never getting reformatted by Excel's auto-detection), keeping the data as JSON further downstream β and only converting to CSV as the very last, human-facing step β avoids surprises.
Arb Digital builds the dashboards, exports, and integrations that turn raw API data into something your team actually uses β from CSV pipelines to full web apps.
See Our Services All Free ToolsCommon Mistakes to Avoid
- Pasting a single object instead of an array. Wrap it in square brackets:
[{...}], not just{...}. - Trailing commas. JSON doesn't allow a comma after the last item in an array or object β trim it before pasting, or run it through our JSON Validator first.
- Assuming column order is guaranteed. Most spreadsheet software treats CSV as a set of named columns, but if you're feeding the file into a strict parser, confirm it reads the header row rather than assuming a fixed position.
- Opening the CSV in Excel with international number settings. Some locales use a semicolon as the default delimiter; if columns look merged, check your regional settings or re-import specifying comma as the delimiter.
- Forgetting that nested arrays lose structure. If you need to preserve full nesting, CSV is the wrong format β keep the data as JSON instead.
Related Free Tools From Arb Digital
Going the other direction? Use our CSV to JSON Converter. Want to double-check your JSON is well-formed before converting? Try the JSON Validator or beautify it with the live JSON Formatter. Working with configuration files instead of data exports? See the XML Formatter and the YAML to JSON Converter. Browse everything in our free online tools hub.
Frequently Asked Questions
No. Parsing and conversion happen entirely in your browser using JavaScript β your data never leaves your device.
The converter collects the union of every key found across all objects and uses that as the header row, filling in empty cells for objects missing a given key.
One level of nesting is flattened into dot-notation columns, for example address.city and address.state, so the data stays readable in a spreadsheet.
They're joined into a single semicolon-separated string, since a CSV cell can only hold plain text, not a list.
Any field containing a comma, a double quote, or a line break is quoted per RFC 4180, with internal quotes doubled, so spreadsheet software parses the row correctly instead of splitting it apart.
Yes β use our CSV to JSON Converter to reverse the process, though flattened dot-notation columns won't automatically re-nest without extra logic.