Parquet to JSON Converter
Open a Parquet file without installing anything. DuckDB runs in the page, reads the schema out of the file, and hands you typed JSON.
To convert Parquet to JSON, drop your .parquet file above. DuckDB compiled to WebAssembly reads it in your browser, using the schema stored inside the file, and each row becomes one JSON object keyed by column name. Choose a pretty array, a minified one, or JSON Lines, then copy or download.
Want to filter or aggregate first? Open the app
The file you were sent and cannot open
Parquet is excellent and it is not human-readable. Somebody sends you one, or you find one in a bucket, and looking at three rows of it requires a Python environment with pyarrow in it, or DuckDB installed, or a Spark session.
That is a disproportionate amount of setup for a question like "what columns does this have" or "does the date range look right". And it is not always possible: a locked-down laptop, a machine you do not administer, a colleague who does not write code.
Dropping the file on a page and reading the answer takes ten seconds and installs nothing.
The schema is in the file, so the types are already right
This is the one conversion on the site that does not have to infer anything. A Parquet file stores its schema alongside its data, so an INT64 column is known to be an integer, a DOUBLE is known to be a double, and a DATE is known to be a date.
Those types come straight through into the JSON: integers as JSON numbers, doubles as JSON numbers, booleans as JSON booleans, dates as ISO strings, nulls as JSON nulls. Nothing is guessed and nothing can be guessed wrong.
There is one place JSON cannot keep up. A very large INT64 exceeds what a JSON number can represent exactly, because JSON numbers are IEEE-754 doubles and lose precision past about fifteen significant digits. Such values come through as strings rather than as silently rounded numbers, which is the only honest option.
Worked example
An orders file, read and emitted:
[
{
"order_id": "ORD-00001",
"placed_on": "2026-01-08",
"region_code": "01",
"units": 12,
"revenue": 1840.5,
"paid": true,
"note": null
}
]region_code is a string because the Parquet schema says it is a VARCHAR, which is exactly what the file's author intended when they wrote it. revenue is a number because the schema says DOUBLE, and it prints as 1840.5 because that is the value stored; the trailing zero it may once have had was formatting, not data.
Nested and repeated columns
Parquet supports nested structures, and files written by Spark or by an event pipeline frequently use them. A struct column comes through as its JSON representation in a single field, and a list column comes through as a JSON array in a single field.
That keeps the row count exactly equal to the file's row count, which is the property everything else depends on. Exploding a list column into extra rows is a real operation with a real name and it belongs in a query, not in a format conversion.
If exploding is what you want, the full editor runs DuckDB with the query surface exposed, and it is one link away from the result panel.
What the file tells you before you convert it
The result panel reports the row count and the column count as soon as the file is read, which is often the whole question. A partner sends a daily extract and the only thing you needed to know was whether today's has the same number of rows as yesterday's.
The column names and their order come from the file's own schema, in the order the writer stored them, rather than being sorted or normalised. That matters when you are comparing two files that should be identical: a reordered column list is a real difference and hiding it would be unhelpful.
Nothing about the file is modified on the way through. This reads and emits; it does not repair, reorder or fill in. A file that DuckDB refuses to open produces the reason it refused rather than a partial result, because a partial read of a columnar file is not a smaller dataset, it is a wrong one.
Why it matters that this runs locally
Every hosted converter for these formats asks you to upload the file. That is a straightforward trade for a photo and a bad one for a data file, because the data files people convert are extracts: customer tables, transaction detail, payroll, event logs with identifiers in them.
Here the engine is compiled to WebAssembly and runs inside the page. The file is read by JavaScript in your tab, the output is produced there, and the download comes from memory. Nothing is sent, stored or logged, and once the page has loaded the whole thing works with the network off.
The practical limit is your tab's memory rather than an upload quota. For files well past a hundred megabytes the full editor streams and is the better route.
Frequently Asked Questions
Do I need Python or DuckDB installed?
No. DuckDB is compiled to WebAssembly and runs inside the page. The engine downloads once, a few megabytes, and is cached. That is the entire point of this page: reading a Parquet file on a machine where you cannot install anything.
Are the types correct?
They come straight from the file. Parquet stores its schema alongside its data, so nothing is inferred here: an INT64 is an integer, a DOUBLE is a number, a DATE is an ISO string, a null is a JSON null.
What happens to a very large integer?
It comes through as a string. JSON numbers are IEEE-754 doubles and lose precision past about fifteen significant digits, so a large INT64 written as a number would be silently wrong. A string keeps the value exact.
How are nested or list columns handled?
A struct comes through as JSON in one field and a list as a JSON array in one field, which keeps the row count identical to the file's. Exploding a list into extra rows is a query operation, and the full editor exposes DuckDB for exactly that.
Can I get one object per line?
Yes, the Structure switch emits JSON Lines. That is the right shape for a large file, since it streams rather than needing the whole document in memory.
Is my file uploaded?
No. It is read by DuckDB compiled to WebAssembly inside your browser tab, and the download comes from memory. Parquet files are usually extracts of something sensitive, which is why this matters more here than on most pages.
Open the Parquet file
Types straight from the schema, no installation, nothing uploaded.
Back to the converter