A reliable JSON to CSV alternative runs the entire conversion in your browser, follows the common RFC 4180 field and record rules, and never uploads your payload to a remote server. That combination is the practical difference between a tool you can hand untrusted records to and one that quietly turns a private API response into a public POST request. The Lizely JSON to CSV converter fits that description: paste a non-empty JSON array of objects, it scans the records in order to discover columns, it quotes commas, line breaks, and nested JSON correctly, and it surfaces the exact same text in the preview that goes into the downloadable converted.csv file. A default safety rule prefixes any string value or header that starts with one of the formula trigger characters (=, +, -, @, tab, carriage return, or an ECMAScript whitespace trigger such as a leading BOM or no-break space) with an apostrophe before CSV escaping, which spreadsheet programs commonly treat as a request for plain text. Limits are explicit and never silent, so a 10,001st row returns an error rather than a shortened file.
Why Developers Look for an Alternative to Python and jq
The most-cited quick path in developer forums is a Python one-liner built on pandas or the csv module, or a piped jq expression. Both work, but each brings setup cost and several correctness traps:
- Python pandas: requires an interpreter with pandas on the path, decides date and number formatting from your locale, and silently drops or coerces values it does not understand.
- Pure Python csv module: needs you to author the quoting and dialect yourself; get it wrong on a comma inside a string and the output is malformed.
- jq with @csv: convenient for quick inspection but applies its own escaping, cannot express always-on formula protection, and is awkward to script against large arrays.
- Server-side online converters: take the opposite trade-off — zero setup, but the array leaves your machine. For developer fixtures and small exports, that round-trip is often a needless risk.
The browser-based alternative keeps the developer's mental model — paste records, get CSV, audit the result — and replaces scripting with a deterministic conversion whose rules are documented in one place.
What "RFC 4180-Style CSV" Actually Requires
CSV looks deceptively simple, but spreadsheets, databases, and analytics tools disagree on which dialect they accept. The most widely referenced baseline is RFC 4180, and a converter worth trusting follows it:
- Fields are separated by commas.
- Records are separated by CRLF line endings.
- A field containing a comma, double quote, carriage return, or line feed is enclosed in double quotes.
- A double quote inside a quoted field is written as two double quotes.
- Empty fields remain empty; no trailing comma is appended.
The Library of Congress describes the same baseline in its CSV format description, framing it as the common interchange shape for tabular data. A converter that does not follow these rules produces a file that looks right in a text editor and breaks the moment a spreadsheet imports it.
The converter emits exactly that shape: comma separators, CRLF record terminators, double-quote wrapping only when needed, and doubled internal quotes. It does not add a UTF-8 BOM, change delimiters based on browser locale, trim whitespace, or infer date and number formats. That determinism is the point — the bytes in the preview are the bytes inside the downloaded Blob.
Converting a JSON Array to CSV Locally
Open the Lizely JSON to CSV converter and follow these steps for a controlled conversion that stays in the current tab:
- Paste a non-empty JSON array of objects into the input area and confirm it stays within the visible limits shown in the counter. A top-level object, primitive, empty array, null row, array row, or primitive row is rejected with a specific message.
- Convert the records. The converter scans the parsed objects in order and adds each field to the header the first time it appears, so later rows can introduce additional columns without breaking the schema.
- Review the preview before downloading. Check column order, the way nested objects and arrays are serialized, quoting on fields that contain commas or line breaks, and the count of formula-risk prefixes reported in the result summary.
- Download converted.csv and, in the receiving application, choose UTF-8 encoding, comma as the separator, and double-quote as the text qualifier.
Editing the JSON after a successful conversion clears the previous CSV output, error, and download URL, so a stale file never lingers in the tab. If the conversion fails, no partial CSV is shown — only the rejection reason. A new conversion also revokes the older Blob URL, and leaving the page releases the remaining one.
Importing the Downloaded CSV Into Excel, Google Sheets, or LibreOffice
Because the file is RFC 4180-shaped, the import settings are predictable. The exact sequence differs slightly between programs.
Excel (desktop, modern versions)
- Double-click converted.csv, or use Data > From Text/CSV.
- When prompted, set File origin to 65001 (Unicode UTF-8) so the BOM-less file decodes correctly.
- Set Delimiter to Comma and Text qualifier to Double quote.
- Confirm that the column data types shown in the preview match what you expect. Cells with a leading apostrophe should display as plain text rather than evaluating as a formula.
Google Sheets
- Use File > Import and upload converted.csv.
- Choose Replace current sheet, Comma as the separator, and set the cell range to A1.
- Confirm the preview shows quoted commas inside string cells as part of the string, not as column breaks.
LibreOffice Calc
- Open converted.csv, or use Insert > Sheet From File.
- Confirm UTF-8 encoding, comma separator, and double-quote text delimiter on the Text Import dialog.
- Decide whether to detect special numbers; for raw data interchange, leave the standard column types set by the wizard.
If a cell starting with an equals sign was prefixed with an apostrophe during conversion, the spreadsheet receives the apostrophe as part of the string and treats the value as text. The apostrophe is not visible in the cell, but it changes how the value evaluates on edit.
Formula Protection: Defending Against CSV Injection
Spreadsheet formula injection happens when a CSV cell carries a string that begins with a character a spreadsheet interprets as a formula trigger — typically =, +, -, or @. When a user opens the file, the spreadsheet can execute the cell as code, fetch external data, or call back to a server. The OWASP community describes CSV injection as an under-appreciated risk in data exports.
The converter's response is an always-on safety policy that you cannot disable through the interface:
- Any field name and any JSON string value that begins with =, +, -, @, tab, carriage return, or an ECMAScript whitespace character (including a leading BOM or no-break space) receives a leading apostrophe.
- The apostrophe is added before CSV escaping, so the resulting field is wrapped in double quotes when needed and the apostrophe is preserved as text inside the quoted value.
- JSON numeric values are typed data and are not prefixed; a JSON number such as -42 remains -42 in the output, because the risk applies to attacker-controlled strings rather than to numerics.
- The conversion summary reports how many cells were prefixed, so the change is visible rather than silent.
This mitigation intentionally changes textual values for safety, and it is not a universal guarantee. A later application might still strip the apostrophe, reinterpret the text, or apply different trigger rules. The OWASP CSV Injection page documents the variants and downstream risks worth reviewing before opening untrusted exports in software that can execute formulas, commands, links, or external data connections.
Explicit Limits That Stop Silent Truncation
A converter that quietly clips oversized input creates a different kind of risk: the data you audit in the preview is not the data in the file. The JSON to CSV converter publishes its bounds up front and never shortens output:
| Boundary | Limit |
|---|---|
| JSON input size | up to 1,000,000 JavaScript characters |
| Array row count | at most 10,000 records |
| Discovered schema | at most 200 unique columns |
| Generated CSV | at most 5,000,000 characters |
Crossing any boundary returns an error and no shortened CSV. The textarea continues to show the over-limit input and the counter marks the overflow rather than cutting characters during typing, so the user always sees exactly what was submitted.
When a Browser Converter Is and Is Not the Right Tool
A local converter fits the case where you control the records, want quick feedback, and want the file to look the same regardless of which spreadsheet opens it: developer fixtures, REST or GraphQL response exports, small one-off data hand-offs to non-developers, and security-sensitive exports that should never leave the tab.
It is the wrong shape for production migrations of regulated data, very large datasets that exceed the published limits, or any pipeline that needs typed columns, a documented encoding declaration, or downstream processing in a specific dialect. CSV does not carry data types, nested schemas, encoding headers, or a universal dialect marker, so anything beyond a flat table is best kept in JSON. If you need the reverse direction, a local CSV to JSON alternative that preserves strings runs the same way and applies the same deterministic rules in the opposite direction.
The conversion is also deterministic only within its published limits and rules: empty rows become empty fields, missing fields become empty cells, nested arrays stay as compact JSON inside one quoted cell, and locale-dependent formatting never enters the pipeline. Treat the preview as the contract. If a value matters more than a flat row — its type, nesting, or trust boundaries — keep the original JSON alongside the CSV and run a schema-aware pipeline for the production step.
For a deeper look, see How to Convert JSON to Excel in Python.