Parquet Viewer & Editor
A Parquet viewer that edits as well as reads. Open a .parquet file, walk its schema, page through ten million rows, change a cell, then save real Parquet or export the view as CSV.
Runs entirely in your browser — your files and text never leave your device.
Drag & drop your file here, or
- Rows
- —
- Columns
- —
- Row groups
- —
- File size
- —
- Compression
- —
Schema
How to use
- Drop a .parquet file on the box marked Open a Parquet file, or press Choose file. It takes .pq too.
- Check the strip that appears: rows, columns, row groups, file size, codecs. Open Schema underneath for the per-column types and nullability.
- Move around with Prev and Next, change Rows per page from its default of 100, or type a row number into Go to row to land on it directly.
- Narrow the view with the Filter box under a column heading, or use Search all rows to sweep the file. Click a heading to sort, click again to reverse it, a third time to drop the sort.
- Double-click a cell to edit it, or focus it and press Enter. Enter keeps the value and Escape abandons it. The ✕ at the start of a row strikes that row through, and the Schema panel handles renaming and dropping columns.
- Choose Snappy or None under Compression, then press Save as Parquet. Export CSV and Export JSON sit beside it, and both write whatever the current filtered, sorted view holds.
About this tool
Parquet is what your pipeline writes and what your laptop refuses to open. Double-click a .parquet file and nothing happens: no preview, no Excel, just a compressed columnar binary that starts with the four bytes PAR1 and hides its index in the footer. So you open a Python REPL, import pandas and wait. That works right up until you are on a borrowed laptop, or on a phone, or holding an extract you would rather not hand to a stranger's server. A Parquet viewer you can point at a file and read is a much smaller ask than that.
Drop the file on the box at the top and the summary strip fills in: rows, columns, row groups, file size, and every compression codec found in the footer. A line under it prints the file's created-by string in full, something like Written by parquet-mr version 1.13.1, build hash and all, which is how you work out which job produced the extract. Open Schema and you get one line per column with its physical and logical type, whether it accepts nulls, and its codec. Then the rows, a hundred to a page unless you move Rows per page to 25, 50, 250 or 500.
Only the row groups you actually look at get decoded, which is the whole reason a file this size is usable in a tab. Parquet keeps its index in the footer, so opening a file means reading the footer and one group, and the cost of a page does not grow as the file does. Filtering, searching and sorting are the exception. Each of those sweeps every row group and puts a progress bar up while it works.
Editing follows the same rule. Double-click a cell and type over it, press the ✕ beside a row to strike it out, rename or drop a column from the Schema panel. Your changes live as a short list keyed by row number, and they get replayed while the file streams through the writer exactly once, so memory tracks how much you changed rather than how big the file is. Undo and Redo cover every edit, and Revert all puts the file back the way it opened.
What ten million rows actually costs
The file this was sized against is a 178 MB extract holding 10,000,000 rows. Reading it into the tab whole would take roughly 3.7 GB of heap, so no code path here ever does. Opening it parses the footer and stops: 36.6 ms. The first hundred rows land in 5.7 ms. Type 500000 into Go to row and the page comes back in 39.7 ms, the same as page one, because a row range only touches the groups that hold it.
Saving is the expensive half. Change one cell in that file, press Save as Parquet, and the whole thing streams past the writer once with your edit applied on the way. 13.5 seconds, peaking at 202 MB, all ten million rows verified at the far end.
Good to know
What this tool leaves out
- A few column types change on the way out. INT96, the 96-bit timestamp older Spark and Impala jobs wrote, comes back as a 64-bit TIMESTAMP. A DATE column does the same. A DECIMAL comes back as a plain number. Every value survives, and the panel above Save as Parquet lists the affected columns before you press it, naming up to three and counting the rest.
- Nested columns, meaning lists, maps and structs, are displayed but cannot be edited. A file whose columns are maps or pre-2.0 repeated groups gets re-saved with a schema inferred from the data instead of the original one.
- Saved files come out Snappy or uncompressed, and that limit is deliberate. hyparquet-writer accepts GZIP, ZSTD, BROTLI and LZ4_RAW, writes the codec name into the metadata, then emits uncompressed bytes anyway, and every reader chokes on the result. So a Zstd source reads fine and re-saves as Snappy, at a different size from the original.
- Filtering, searching and sorting all sweep every row group and keep the first 200,000 matching rows. Sort a ten-million-row file and you are sorting 200,000 of them. The pager says capped when that happens, so at least you know.
What a browser cannot do
- The edited file is assembled in memory before the browser hands it to you, so the file you save has to fit in the tab even though the file you opened does not.
- A browser cannot write back to the file you opened. Saving produces a download, and the original on disk is left alone.
Frequently asked questions
How big a file can it open before it falls over?
Bigger than you would guess, because it never reads the whole thing. Parquet stores rows in groups and puts an index in the footer, so opening a file means reading the footer, and reading a page means touching one group. A 178 MB file with ten million rows in it opens in well under a second and pages just as fast at row nine million as at row one. Saving is where size starts to bite, since the file you write has to fit in the tab.
Which compression codecs can it read?
Snappy, Gzip, Zstd, Brotli, LZ4, LZ4_RAW and uncompressed. LZO is the only codec in the specification it cannot read, and nothing current writes LZO anyway. Writing is narrower than reading: Snappy or uncompressed, chosen from the menu next to the save button.
I changed one cell. Why does the whole file get rewritten?
Because Parquet is columnar and compressed, there is no byte in the file corresponding to one cell. Values are dictionary-encoded, bit-packed and compressed in column chunks, and patching one in place would corrupt the chunk around it. Your edits are held as a list keyed by row number and applied while the file streams past the writer, so the cost tracks how much you edited rather than how large the file is.
How do I turn a Parquet file into a CSV?
Press Export CSV. It writes the view you are looking at, so if you filtered down to 43 rows and sorted them by date, that is what lands in the file. Export JSON sits next to it and works the same way. Both downloads keep the name of the file you opened.
How do I put a NULL back into a cell?
Empty the cell and press Enter, or type the word null in any casing. Both land as a real null rather than a four-letter string. Anything the column cannot hold is refused with a message naming the trouble, so 4.5 in an INT32 column comes back as not a whole number and the old value stays put. Retyping a value that matches the original quietly drops the edit instead of counting as one.
Can the column filter do greater than, or is it text matching only?
Text matching, case-insensitive, asking whether the formatted value contains what you typed. No operator syntax exists, so a filter of 5 on a price column pulls in 5 and 250.50 alike. Sort the column and page to the boundary when you need a range. Search all rows behaves the same way, except it checks every column at once.
Why are my big numbers wrapped in quotes in the JSON export?
Only the 64-bit ones are. Parquet INT64 runs past what a JavaScript number can hold exactly, so writing 9007199254740993 as a bare JSON number would quietly round it to an even neighbour. Quoting keeps every digit. Timestamps come out as ISO strings for related reasons, and raw byte columns come out as arrays of numbers.
Missing something in Parquet Viewer & Editor? Suggest a feature →