Parquet editor online

Steps

1. 1

   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.

2. 2

   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.

3. 3

   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.

Editing Parquet in pandas, for comparison

import pandas as pd
df = pd.read_parquet("in.parquet")
df.loc[df["status"] == "pendng", "status"] = "pending"
df.to_parquet("out.parquet", index=False)

Four lines, and the right tool once the fix is known. The catch is what pandas does to the schema on the way through: an integer column that contains nulls comes back as float64 unless you pass dtype_backend="pyarrow", and the rewritten file then carries a different type from the original. The editor here keeps the column type from the file and shows you what would not cast before anything is written.

What a Parquet editor cannot do, anywhere

Append rows to an existing .parquet in place, edit a single row group, or change the compression of a file without rewriting it. Those are properties of the format, not of this tool: a Parquet file is written once, with its footer last, and every editor produces a new file. What you can choose at export is the codec — Snappy, Zstandard or none — and whether the edited table goes back out as Parquet or as CSV, JSON, Arrow or Excel.

Frequently asked questions

More Parquetbay tools

• Parquet to CSV converter
• CSV to Parquet converter
• Parquet to JSON converter
• Parquet to Excel converter

Open the full Parquetbay workbench →