How to use this calculator
How the column set is built
JSON-to-CSV flattens an array of objects into a spreadsheet-ready table, and the first job is deciding the columns. The converter takes the union of every object’s keys in first-seen order: the first object contributes its keys in order, then new keys from later objects are appended. That is the behavior that keeps the output correct when rows disagree — an API response where one user has a city and another does not produces a name, age, city table with an empty cell where city is missing, and every row lines up with the header.
The input contract is strict because the output needs a stable shape: the converter requires a non-empty array of objects. A bare object, an array of strings, or an empty array is rejected with a message that says what was wrong, rather than guessed into a structure that would break downstream.
What happens to values that are not simple text
CSV cells are text, so values are serialized the way the format allows: missing keys become empty cells, null and undefined become empty cells, and nested values — an object or array inside a cell — are serialized as JSON strings, so {"x":1} stays the text {"x":1}. That is the only lossless flat representation: the nested data survives verbatim in the cell, and any spreadsheet software shows it as text.
Numbers and booleans are written as their plain forms (30, true), which is the natural convention for spreadsheet imports. True flattening of deep structures — turning every nested key into its own column — is outside the converter’s scope, and the page says so rather than pretending otherwise.
Quoting and line endings: the RFC 4180 contract
The output follows RFC 4180 exactly so every spreadsheet application opens it correctly: cells containing a comma, a quote, or a line break are wrapped in double quotes, embedded quotes are doubled (""), and rows are terminated with CRLF — the line ending the standard defines and the one spreadsheet tools expect. The worked example shows the pair in action: the cell "New York, NY" is quoted because of its comma, and the file ends every row with CRLF.
Getting these details right is the difference between a file that opens cleanly and one that splits columns or misaligns rows. The converter never produces the unquoted forms that break on the first address containing a comma.
The local promise
API responses, database exports, and test data often contain internal details that should not leave your machine, and converting JSON to CSV is a job no server needs to perform. Everything runs in your browser: the JSON is parsed and serialized locally, nothing is uploaded, logged, or stored, and copy and download actions deliver the CSV file where you need it — a spreadsheet, an import tool, or a stakeholder who asked for the data in a readable form.
Frequently asked questions
How are nested objects converted?
Nested values are serialized as JSON strings inside the cell — for example {"x":1} becomes the text {"x":1}. CSV is a flat format, so deeper structures need flattening or a separate export.
What is the column order?
Columns follow first-seen order across the array: the first object contributes its keys in order, then new keys from later objects are appended. Every row lines up with the header regardless of which object has which keys.
Why does my file end with CRLF?
CRLF is the line ending of RFC 4180 and the convention spreadsheet applications expect. The converter emits it by default so files open correctly everywhere.
Can I convert an object instead of an array?
No — the converter requires a non-empty array of objects, because that is the shape that maps to rows. A bare object is rejected with a clear message; wrap it in an array if that is what you have.
Why do my null values come out as empty cells?
Null and undefined mean "no value here" in JSON, and an empty cell is the honest CSV equivalent — the column position is preserved, and the spreadsheet shows the absence rather than a placeholder that could be mistaken for data.