How to Turn an API Response Into a Spreadsheet (Without Uploading Your Data)

An API response is usually JSON: a list of objects, where each object is one record and each field inside it is one piece of information. A shop's order list might look like this, shortened to three orders:

• Order 101: Sara, S., sara@example.com, address in Lahore with postcode 54000, items mug and notebook, total 42.5.
• Order 102: Omar, omar@example.com, address in Karachi with no postcode recorded, item mug, total 12.0.
• Order 103: Lee, lee@example.com, address in Boston with postcode 02134, no items, total 0.

Three features of that shape cause every spreadsheet problem in this guide. First, fields are nested: the postcode lives inside an address object, not beside the name. A spreadsheet has no nesting, so something has to flatten address into address.city and address.zip. Second, fields are sometimes missing: Omar has no postcode, so his row needs an empty cell, not a shifted row. Third, some fields are lists: Sara bought two items, and one spreadsheet cell has to hold both. If you want the background on the format itself, read What Is JSON? first; the rest of this guide assumes you can recognise a JSON array when you see one.

There is also a common wrapper shape to watch for. Some APIs do not return the bare list; they return one object holding the list under a single key, like {orders: [...]}. That is still the same list, just wearing a coat. Our converter unwraps a single-key object like that automatically, so you can paste either shape and get the same rows.

1. Validate first. Paste the JSON into our JSON Formatter and confirm it parses. A missing comma or an unclosed bracket is far easier to find in a formatter, which points at the problem, than in a converter that just says no.
2. Paste it into the JSON to CSV Converter. A JSON array of objects, a single object, an array of plain values, or a single-key wrapped array all work. A bare number, string, or true/false does not, because it has no columns to map.
3. Check the header row and the preview before you download. The headers are the union of every field in every row, in the order they first appear, and nested fields show up in dot form, like address.city. If a header looks wrong, the JSON is usually the problem, not the converter.
4. Choose your delimiter. Comma is the default and the right choice for most people. Pick semicolon if your spreadsheet program expects it — common in locales where the comma is the decimal separator — or tab if the file is headed for a system that asks for tab-separated values.
5. Open the file properly, not just quickly. Double-clicking a CSV in Excel is fast and is also how postcodes lose leading zeros, as the next-but-one section explains. Use your spreadsheet's import dialog and set ID and postcode columns to Text. The extra thirty seconds saves the most common data-loss complaint in this whole workflow.

That is the whole workflow, and it stays in your browser tab from start to finish. Nothing you paste is sent to a server, which matters a lot more here than it does for, say, a unit conversion — an API response can contain customer names, email addresses, order histories, and internal IDs in a single paste.

Here is the three-order list from the first section, converted exactly as the tool converts it. The result has 3 rows and 7 columns, with headers id, name, email, address.city, address.zip, items, and total:

• 101, "Sara, S.", sara@example.com, Lahore, 54000, mug; notebook, 42.5
• 102, Omar, omar@example.com, Karachi, (empty cell), mug, 12.0
• 103, Lee, lee@example.com, Boston, 02134, (empty cell), 0

Every interesting decision is visible in those three lines. Sara's name contains a comma, so it is wrapped in quotes; without the quotes, the comma would split her name across two columns. Omar's missing postcode becomes an empty cell, so his total stays in the total column instead of sliding one place left. Sara's two items share one cell, joined with a semicolon and a space, because a flat spreadsheet row cannot hold a list any other honest way. And Lee's Boston postcode, 02134, survives in the file exactly as written, leading zero included — the file is correct, and the danger is only in how a spreadsheet program opens it, which is the next section's second trap.

One more shape is worth knowing: a list of objects inside a record has no honest flat form, so the converter keeps it as JSON text in its cell rather than silently dropping it or inventing columns. You will see that with line items that carry their own prices and quantities. If a record's items each need their own row, that is a different conversion — one row per item — and a flat converter is the wrong tool for it. Say so in your report rather than forcing it.

Trap 1: commas and quotes inside the data

A naive converter that joins fields with commas and never quotes anything will break on the first name like Sara, S. or the first note containing a quotation mark. The rule that keeps a CSV file intact is simple: any field containing the delimiter, a quote, or a line break gets wrapped in quotes, and quotes inside it get doubled. Our converter follows that rule, which is why Sara's name comes out as "Sara, S." and a note saying he said hi comes out with its quotes doubled. If a file you received looks shifted — values landing in the wrong columns from one row onward — broken quoting in the file is the first suspect.

Trap 2: spreadsheets reinterpreting numbers

This trap is not in the CSV file at all; it is in the program that opens it. A CSV file stores text, but a spreadsheet program guesses a type for every column when you double-click the file. Postcode 02134 becomes 2134 because the program reads it as a number. A 16-digit order or account ID is worse: Excel keeps only 15 significant digits, so the last digit silently becomes zero, and the ID no longer matches anything. The fix is at import time: in Excel, use Data, From Text/CSV, and set postcode and ID columns to Text before loading; in Google Sheets, use File, Import, and choose No for Convert text to numbers, dates and formulas where offered. The file was right all along — the import settings were the problem.

Trap 3: the wrong delimiter for your locale

In many European locales the comma is the decimal separator, so spreadsheet programs there expect semicolon-separated files. Open a comma-separated CSV in such a setup and every row lands in a single column. The converter offers a semicolon delimiter for exactly this case, and note the knock-on effect: with a semicolon delimiter, Sara's items cell, mug; notebook, now contains the delimiter, so it gets quoted as "mug; notebook". That is the quoting rule doing its job, not an error.

Trap 4: dates and times silently changing meaning

A date written as 03/04/2025 means 3 April in most of the world and March 4 in the United States, and a spreadsheet program will pick its own locale's reading without asking. If your JSON carries dates, check a few converted rows against the original before you send the file on, and prefer the unambiguous ISO form, 2025-04-03, in the JSON itself where you control it. The same caution applies to times: a timestamp in seconds since 1970 is not a date to a spreadsheet, so convert it to a readable date first if your readers need one.

Most online converters are free because they run on a server, and a server-side converter receives your data. For a list of product names that hardly matters. For an API response it can matter a great deal, because one paste can contain customer names, email addresses, delivery addresses, and order histories — other people's personal data, which you may be handling under a contract or a privacy law that does not have an exception for convenience.

A browser-only converter avoids the whole question: the parsing and the file building happen in your tab, and the data never leaves your device. That is the same reason this site's other tools work the way they do, and it is the reason I would not paste a real customer export into any converter that uploads it, however slick its interface. Convenience is not a data-processing agreement.

Two habits complete the picture. First, convert only the fields you need: if the report needs names and totals, strip email addresses and full addresses from the JSON before converting, rather than converting everything and deleting columns afterward. Second, treat the downloaded CSV with the same care as the original export, because it is now a second copy of the same personal data sitting in your downloads folder.

My API returns one object like {orders: [...]} instead of a bare list. Will it convert?

Yes. When a single object holds exactly one key and that key's value is an array, the converter unwraps it and converts the array. Paste it as it came from the API; you do not need to strip the wrapper by hand.

What happens to rows that are missing a field?

They get an empty cell in that column, and every other value stays in its own column. The headers come from all rows combined, so a field that appears only in later rows still gets its own column, with empty cells in the earlier rows.

Why did Excel turn my postcode 02134 into 2134?

Because double-clicking a CSV lets Excel guess each column's type, and it guessed number. The file itself still says 02134. Re-import it through Data, From Text/CSV, set the postcode column to Text, and the zero survives. The same fix protects long IDs, which Excel otherwise truncates to 15 significant digits.

Should I use a comma or a semicolon delimiter?

Comma, unless your spreadsheet program expects semicolons — which is common in locales where the comma is the decimal separator. If a comma-separated file opens with every row crammed into one column, a semicolon file is almost certainly what your setup wants.

Can I convert a single JSON object, not a list?

Yes, it becomes a one-row spreadsheet with the object's fields as columns. An array of plain values works too, becoming a single column called value. Only a bare number, string, or true/false is rejected, because it has no columns to map.