Apache Parquet
Parquet is a typed, compressed, columnar file format built for analytical workloads. It is the storage layer under most modern data platforms, and it is deliberately unreadable without a tool.
- Type information
- Full — ints, floats, booleans, timestamps, decimals
- Structure
- Columnar, with nested type support
- Compression
- Built in (Snappy, Gzip, Zstd)
- Typical file size
- Typically 5–15% of the CSV
- Schema
- Stored in the file footer
- Human-readable
- No — binary
- Tool support
- Spark, DuckDB, pandas, BigQuery, Athena
ParquetCSV
Runs on your deviceOptions
Reading Parquet
Auto-detect reads the first rows and picks the separator that splits them consistently.
Turn off when the file starts straight into data. Columns are then named column_1, column_2, and so on.
Turns "42" into a number and "true" into a boolean. Values with leading zeros stay text so IDs and zip codes survive.
Which worksheet to convert. Filled in once the workbook is read.
Dotted path to the array of records, such as data.items. Leave empty to use the whole document.
Turns {"user":{"id":7}} into a user.id column. Arrays are kept as JSON text.
Pick the encoding the file was written in. Wrong encoding shows up as garbled accents.
Comma-separated words that should become null instead of text.
Writing CSV
Snappy is the default across Spark, DuckDB and pandas. Gzip is smaller but slower to read.
Turns a user.id column back into {"user":{"id":7}}.
Excel needs a byte order mark to open UTF-8 files with accents correctly.
Rows per row group. Larger groups compress better; smaller groups let readers skip more.
conversion-preroll
This short ad is what keeps the converter free.
The defining choice is columnar storage: instead of writing row one, then row two, Parquet writes all of column one, then all of column two. Values of the same type sit next to each other, which compresses far better than mixed row data, and lets a query engine read only the columns a query mentions. A query touching two columns of a fifty-column table reads roughly 4% of the file.
On top of that, Parquet stores a real schema in its footer, along with statistics — minimum, maximum and null count — for each chunk of rows. An engine can use those statistics to skip entire row groups without decompressing them. This is why a filtered query over a large Parquet file can return before a CSV of the same data has finished being read.
The trade-off is that you cannot look at it. There is no text editor view, no head command that shows you anything useful, and no way to check a value without a library that understands the format. That is the tax for the performance, and it is the reason Parquet tooling exists at all.
What Parquet is good at
- Typically 5–15% of the size of the equivalent CSV.
- Full type system: integers, floats, booleans, timestamps, decimals and nested structures.
- Column pruning and row-group skipping make analytical scans dramatically faster.
- Schema travels inside the file, so types survive every handoff.
- Read natively by Spark, DuckDB, pandas, Polars, BigQuery, Athena and Snowflake.
Where it falls short
- Binary — unreadable without tooling, which makes casual inspection impossible.
- Poorly suited to row-by-row appends; it is written in batches.
- Not supported by Excel, Google Sheets, or most business software.
- Encrypted variants need key management that a browser tool cannot provide.
Convert Parquet files
From Parquet
To Parquet