CSV to Parquet converter — how it works
Converting CSV (plain comma-separated text) to Parquet (a columnar, compressed analytical file format) happens entirely in your browser. CSV carries no type information, so delimiter and header detection matter; Parquetbay sniffs both when they are ambiguous. Parquet stores columns separately with per-column compression (Snappy, Zstandard or none), so it is far smaller and faster to scan than row-based text. Column types are written into the file schema, so numbers, dates and booleans survive the round trip instead of degrading to strings.
- Cost
- Free; no account required
- Processing
- Local, inside the browser tab
- Privacy
- File contents are not uploaded
Steps
-
Open the CSV file
Drop or select a .csv file. The delimiter and header row are detected on read, and DuckDB infers a type for each column.
-
Check the inferred types
This is the step worth not skipping. Open the column profiler and confirm the types before export — whatever is inferred here is what gets written into the Parquet schema, and fixing it afterwards means converting again.
-
Export as Parquet
Open the Export panel, choose Parquet, pick a compression codec, and download the .parquet file.
Details that matter
The same thing in the DuckDB CLI
COPY (SELECT * FROM read_csv('data.csv')) TO 'data.parquet' (FORMAT parquet, COMPRESSION zstd);DuckDB defaults to Snappy when no codec is given; Zstandard usually produces a noticeably smaller file for a little more CPU. Reach for the CLI when this runs on a schedule — stay here when you want to eyeball the inferred types first, which is the step that actually goes wrong.
Checking that nothing is uploaded
You do not have to take the privacy claim on faith. With the Network panel of your browser’s developer tools open, load a CSV and export it: you will see this site’s assets and the DuckDB WebAssembly module load, and nothing carrying your rows.
When to leave it as CSV
Parquet earns its keep on files that get scanned repeatedly or moved between systems. For a handful of rows that a colleague will open once in a spreadsheet, converting adds a format they may not be able to read for a size win measured in kilobytes. Convert when the file is large, queried often, or crossing a tool boundary.
Limits and behaviour worth knowing
Type inference reads a sample of the file, not all of it, so a column that looks numeric for thousands of rows and then contains one dash can be inferred as a number and fail later. The profiler shows you what was inferred. Zero-padded identifiers are the classic casualty — force them to text before export if the leading zeros matter. Compression choices are Snappy, Zstandard or uncompressed.
Frequently asked questions
Do CSV column types carry over to Parquet?
Yes — that is most of the reason to convert. DuckDB infers types as it reads, and those types are written into the Parquet schema, so numbers, dates and booleans arrive as real types instead of text. Review them in the column profiler before you export.
Which Parquet compression should I pick?
Snappy is the balanced default and what most readers expect. Zstandard produces smaller files at some CPU cost. Uncompressed is only useful when you are debugging the file itself.
My IDs have leading zeros — will they survive?
Only if the column is typed as text. A column of digits is inferred as an integer by default, and 007 becomes 7. Set the column to text before exporting when the zeros are part of the identifier.
How large a CSV can I convert?
There is no fixed limit; the practical ceiling is your device’s memory. Only visible rows are rendered and DuckDB scans columnar data efficiently, but an export still needs working memory beyond the data itself.