Parquet to JSON converter — how it works
Converting Parquet (a columnar, compressed analytical file format) to JSON (a structured array of records) happens entirely in your browser. Because Parquet is a binary columnar format, a text editor or spreadsheet cannot open it directly — it needs a reader that understands the schema. JSON keeps a readable, nested structure and is easy to consume from almost any language, at the cost of larger size and slower scans than columnar formats.
- Cost
- Free; no account required
- Processing
- Local, inside the browser tab
- Privacy
- File contents are not uploaded
Steps
-
Open the Parquet file
Drop or select a .parquet file. Its schema and rows are read on your device.
-
Decide what a record should contain
JSON is verbose, so a Parquet file converted whole can be several times its original size. Drop the columns the consumer does not read, or filter to the rows that matter, before exporting.
-
Export as JSON or NDJSON
Open the Export panel and pick JSON for a single array of records, or NDJSON for one object per line. Both download straight from the browser.
Details that matter
The same thing in the DuckDB CLI
COPY (SELECT * FROM read_parquet('data.parquet')) TO 'data.json' (FORMAT json, ARRAY true);Leaving out ARRAY true writes newline-delimited JSON instead of an array — which is usually what a bulk-load API or a log pipeline actually wants. Use the CLI inside a pipeline; use this page when you need to read the data before deciding what shape to emit.
Checking that nothing is uploaded
Confirm it for yourself: open the Network tab in developer tools before loading a file. Parquet reading and JSON writing both happen inside the tab, so the panel shows page assets and the WebAssembly engine — no upload of your data.
When JSON costs more than it gives
JSON repeats every key on every record, so a columnar file that compressed well can expand several-fold and lose the type information that made it fast to scan. If the destination understands Parquet or Arrow, send it that. JSON is the right answer when something needs to read the data without a columnar reader.
Limits and behaviour worth knowing
Integers, floats, booleans and strings map onto their JSON equivalents. Timestamps become ISO-8601 strings, since JSON has no date type. Very large 64-bit integers can exceed what a JavaScript consumer represents exactly — if the values are identifiers rather than quantities, emit them as strings. Nested struct and list columns keep their shape rather than being flattened.
Frequently asked questions
JSON array or NDJSON — which should I choose?
JSON for a single array a script will parse in one go. NDJSON for anything streaming, appending, or feeding a bulk-load API, because each line stands alone and the whole file never has to be held in memory.
Are Parquet types preserved in the JSON output?
As far as JSON allows. Numbers, booleans and strings map directly; timestamps become ISO-8601 text because JSON has no date type of its own.
Can I filter or reshape before exporting?
Yes. Run DuckDB SQL over the table, or add filter and column steps, then export the result. Worth doing here specifically — JSON is bulky, so exporting only what is needed can shrink the output by an order of magnitude.
Will huge integer IDs survive the trip?
They are written correctly, but a JavaScript consumer parsing them with the default number type loses precision above 2^53. Cast such columns to text before export when they are identifiers.