JSON to CSV Converter

About JSON to CSV Converter

JSON to CSV Converter is a free online tool that converts JSON (JavaScript Object Notation) data into CSV (Comma-Separated Values) format. Upload a JSON file or paste JSON data, choose your CSV delimiter and options, and download the converted CSV file—all processed locally in your browser for complete privacy.

How do I handle nested JSON when converting to CSV?

CSV is fundamentally flat — every row is a sequence of scalar values — while JSON allows arbitrary nesting. The converter offers three strategies. Dot-notation flattening turns {"user":{"name":"Alice","age":30}} into columns user.name and user.age, the most common choice for analytics. JSON-string flattening keeps the nested object as a single quoted JSON value in one column, useful when you want to round-trip the document or load it into a database that has a JSON column type. Array explosion (sometimes called unwind, after MongoDB's $unwind operator) duplicates the parent row once for each item of a nested array, suitable when each array element should become its own record. For deeply nested or recursive structures, consider exporting to NDJSON instead — RFC 4180 was never designed for hierarchical data, and forcing it always loses information.

What if my JSON objects have different keys from one record to the next?

This is the schema heterogeneity problem and it is the rule, not the exception, with JSON from real APIs. The converter scans every record to compute the union of all keys, then emits a single header row containing every key it found and writes an empty value in cells where a particular record had no value for that column. The result is a sparse but rectangular CSV that every spreadsheet and SQL importer can read. If you want only the keys present in the first record (useful when later records have noisy extra fields you want to drop), enable "Use first record schema." If different records have genuinely incompatible shapes — say, half are users and half are orders — split the input into two passes and produce two CSVs rather than forcing them together.

How are arrays of primitives like ["red", "green", "blue"] handled?

By default an array of primitives is joined into a single cell with a configurable separator (comma, semicolon, or pipe) — so ["red","green","blue"] becomes red;green;blue if you choose semicolons. This keeps the row count stable but makes downstream parsing in Excel awkward because Excel cannot easily split a single cell. The alternative is array explosion: the row is duplicated three times with one colour per row, which gives you a tidy long-format table familiar to Pandas and R users. A third option is index columns: the array becomes colors.0, colors.1, colors.2 columns, which preserves order and is round-trippable but wastes space when array lengths vary widely. Pick the option whose downstream tool — Excel, SQL, BI dashboard — handles best.

Why does Excel mangle UTF-8 characters like é, ñ, or 中 in my exported CSV?

Excel for Windows historically opens CSV files using the system's default code page (often Windows-1252 in Western locales) rather than UTF-8, which corrupts any non-ASCII character. The standard fix is to prepend a UTF-8 byte-order mark (EF BB BF) to the file — this BOM tells Excel "interpret this as UTF-8" and the characters render correctly. This converter offers a "UTF-8 with BOM" option in the output settings, on by default for compatibility. Modern Excel (365 and 2021+) and all versions of Excel for Mac handle BOM-free UTF-8 correctly. If you control the recipient's workflow, prefer importing through the Excel "Data → From Text/CSV" wizard and selecting the 65001 (UTF-8) code page explicitly — that path works for every Excel version without modifying the file.

How does the converter escape values that contain commas, quotes, or newlines?

The converter follows RFC 4180 strictly. Any field containing the delimiter, a double quote, or a line break (LF, CR, or CRLF) is wrapped in double quotes, and every literal double quote inside the field is doubled. For example, the string She said "go, now" with an embedded newline is encoded as "She said ""go, now""\n" with a real newline inside the quotes. This produces a file that round-trips faithfully through Excel, Google Sheets, LibreOffice, Pandas read_csv, and PostgreSQL COPY — provided those readers also follow RFC 4180, which all modern tools do. If you target a non-conformant legacy reader, you can switch the converter to "always quote" mode, which wraps every field unconditionally and is the safest setting for any unknown consumer.

Can I choose which JSON fields become CSV columns and in what order?

Yes. By default columns appear in the order keys are first encountered as the converter walks the input, but you can override this completely. The "Column selector" panel lists every detected key (with dot paths for nested fields) and lets you drag-reorder them, hide unwanted columns, and rename headers without changing the underlying JSON path. You can also paste an explicit ordered list of columns from a template if you need the output to match an existing schema such as a downstream import format. Renaming is purely cosmetic and the original JSON path is preserved internally so re-running the conversion on a refreshed input produces the same column shape.

What is the best way to convert a multi-gigabyte JSON file to CSV?

Loading a multi-gigabyte JSON document into a browser will exhaust memory long before the converter does anything useful. The right approach is streaming conversion at the command line: jq -r 'paths(scalars) as $p | [($p|join(".")), getpath($p)] | @csv' is a one-liner for flat-ish documents, and tools like Miller (mlr --ijson --ocsv cat input.json > output.csv), DuckDB (COPY (SELECT * FROM read_json_auto('input.json')) TO 'out.csv' (FORMAT CSV)), and the Python ijson library all walk the document event-by-event without materialising it. If the source is already NDJSON (one JSON object per line), simply pipe it through Miller or jq line-by-line for almost unbounded scalability. Use this browser converter for documents up to roughly 50 MB; switch to command-line streaming beyond that.

How do I preserve JSON data types like booleans, nulls, and numbers in the CSV?

CSV has no type system — every cell is text — so the converter chooses textual representations. Booleans become the literal strings true and false (configurable to 1/0, Yes/No, or True/False). Null becomes an empty cell by default; many SQL importers treat empty cells as NULL automatically, but you can opt to emit the literal string null or a sentinel like \N (Postgres COPY's default) if you need to distinguish empty string from null on import. Numbers are emitted in their native decimal form, which is fine for most values, but large integers beyond Number.MAX_SAFE_INTEGER (2^53 − 1) suffer the standard JavaScript precision loss — if your JSON quotes big integers as strings ("id": "9007199254740993"), this converter preserves the string form unchanged and your downstream system can re-parse them with BigInt.