An API response comes back as JSON. The person who actually needs the data usually wants it in a spreadsheet. That gap - structured, nested data on one side, rows and columns on the other - is one of the most common reasons anyone reaches for a JSON-to-CSV or JSON-to-Excel converter, and it’s worth understanding exactly how the conversion works before you rely on it for something that matters.
What converts cleanly, and what doesn’t
An array of objects is the ideal shape. [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}] becomes exactly what you’d expect: one row per object, with the union of every key that appears across all the objects used as the column headers, in the order those keys first appear. If one object has a field the others don’t, that cell is simply blank for the rows that lack it.
A single object becomes a single row. If your JSON is one object rather than an array of them, you get a one-row table - useful for a single API resource rather than a list endpoint.
An array of plain values (not objects) becomes a single-column table. ["a", "b", "c"] converts to a CSV with one column and three rows. There’s no meaningful way to spread bare values across multiple columns without more structure to work from.
Nested objects and arrays
Real API responses are rarely flat. A user field that’s itself an object - {"user": {"name": "Alice", "email": "a@example.com"}} - doesn’t have an obvious single CSV cell to live in, so it gets flattened into dot-notation columns instead: user.name and user.email as two separate columns, rather than one column holding a JSON blob.
A nested array is a different problem: there’s no clean way to represent “this row has a list inside it” as a single tabular cell without inventing extra rows, which would change what each row means. The practical compromise, and the one Jsontify’s JSON to CSV and JSON to Excel converters use, is to write the nested array as a compact JSON string inside that one cell - it’s not spreadsheet-native, but it preserves every value rather than silently dropping data, and it’s still readable if you click into the cell.
Numbers, and where CSV and Excel diverge
Plain CSV has no native number type - every value is text, and it’s up to whatever opens the file to guess. Numbers convert as-is from the source JSON, with one exception: an integer with more than about 15-16 significant digits is written as text rather than a spreadsheet-parseable number, because letting a spreadsheet application re-parse it as a floating-point number would silently change the value. A 19-digit database ID is exactly the kind of number this protects - the alternative, converting it through a float, would round it to something else entirely without any visible warning.
Excel’s .xlsx format does have real numeric and boolean types, so the Excel export keeps those where it’s safe to - numbers stay numeric (so they sort and sum correctly in the spreadsheet), booleans stay boolean - while the same oversized-integer rule still applies for anything too large to represent exactly.
Special characters
Commas, double quotes, and line breaks inside a value all have meaning in the CSV format itself, so a value containing any of them is automatically quoted and escaped per the CSV standard. A product description with a comma in it, or a multi-line address field, both round-trip correctly when the resulting file is reopened - you don’t need to sanitize your JSON before converting it.
Doing the conversion
Paste your JSON into Jsontify, and the conversion happens the moment you choose CSV or Excel from the Export menu - no upload step, since the whole thing runs in your browser. That matters in the ordinary case (a large export you’d rather not wait on a server for) and in the case where the JSON is something you’d rather not send to an unfamiliar server at all: a real customer record, an internal API response, anything with data in it that isn’t yours to hand off casually. Conversion happens entirely client-side - nothing is uploaded to our servers.