Parquet editor online — how it works
Parquetbay opens a .parquet file into an editable grid backed by DuckDB compiled to WebAssembly. You can change cell values, add or delete rows and columns, find and replace across a column or the whole table, and stack undoable transform steps. Exporting writes a brand-new Parquet file; the original on disk is never touched.
- 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. It is read locally, and the copy on disk stays exactly as it was for the whole session.
-
Make auditable edits
Edit cells directly, add or remove rows and columns, find and replace values, and reorder or disable transform steps. Every change lands in a journal you can review and undo, so an edit made twenty steps ago is still traceable.
-
Export a new Parquet file
Open the Export panel, keep Parquet selected, choose a compression codec, and download the edited result as a fresh .parquet.
Details that matter
The same thing in the DuckDB CLI
COPY (
SELECT * REPLACE (upper(status) AS status)
FROM read_parquet('input.parquet')
) TO 'output.parquet' (FORMAT parquet);Note what the CLI version makes obvious: there is no UPDATE here. Parquet files are immutable, so every edit — in DuckDB, in Spark, or on this page — is really a read, a transform and a rewrite. The difference is that a script needs the change expressed as SQL in advance, while this page lets you find the problem by looking at the data.
Checking that nothing is uploaded
The claim that editing stays local is one you can test in a minute. Open developer tools at the Network panel, load a file, change some cells and export: the panel lists this page’s assets and the DuckDB WebAssembly module, and nothing else. No request carries a row of your data.
When to reach for a pipeline instead
Hand-editing is right for a bad value, a wrong header, a column that needs renaming before someone else loads it. It is the wrong tool for a correction that has to be reproducible — if the same fix must apply to next month’s file too, write it as SQL and run it in a job. Use the journal here to work out what the fix should be, then move it into the pipeline.
Limits and behaviour worth knowing
There is no fixed row cap; device memory and the file’s encoding set the ceiling, and editing needs working memory beyond simply reading. Edits are held in memory until you export — closing the tab discards them, by design, because nothing is stored on a server. Changing a column’s type rewrites that column, so a value that will not cast shows as null rather than silently becoming something else.
Frequently asked questions
Can you really edit a Parquet file in the browser?
Yes, with one clarification worth understanding: Parquet is immutable, so nothing edits the original. Changes are applied in memory and a completely new file is written on export. That is equally true of DuckDB and Spark — an in-place Parquet edit does not exist anywhere.
Are my edits reversible?
Yes. Cell edits and transform steps are recorded in a journal you can review, reorder, disable or undo before exporting, so a change made early in a session can still be unpicked at the end.
What happens if I close the tab?
Unexported edits are lost. There is no server-side draft, because there is no server involved — which is the same property that keeps the data private. Export when you have something worth keeping.
Can I edit a column’s name or type, not just its values?
Yes. Columns can be renamed, reordered, added, dropped and retyped, and each of those lands in the journal as a step. Values that cannot cast to a new type become null rather than being coerced into something misleading.