CSV Diff Tool

Compare two CSV exports row by row, matched on a key column of your choice, and see exactly which rows were added, removed or changed. Nothing is uploaded.

Loading tool…

Worked examples

  • A price change, a removed row and a new row

    The everyday case: a product catalog export compared to the current one, matched by id — one row's price moved, one product was discontinued, one was added.

  • Two identical exports

    Confirms two inventory snapshots exported at different times contain the same data, with no rows worth reviewing.

  • A plan upgrade and a new signup, keyed by email

    A subscriber list compared by email address rather than row position, which is what matters when rows can be reordered or inserted between exports.

What this tool does

This tool compares two CSV exports row by row, matched on a key column you choose — such as id, sku or email — rather than by row position. It reports which rows were added, removed or had a field change, and for changed rows, exactly which columns differ and their old and new values.

When you need it

  • Comparing two exports of the same table — a product catalog, a customer list, an inventory report — pulled a day or a week apart, to see what actually changed.
  • Reviewing a bulk data update before applying it, by diffing the proposed CSV against the current one.
  • Auditing a data migration or ETL job by comparing its output against a known-good snapshot.
  • Spotting rows that were accidentally dropped or duplicated between two versions of a spreadsheet export.

Why matching by key column matters

Rows in a CSV export can be reordered, filtered, or have new rows inserted between two snapshots of the same underlying data — a spreadsheet tool might resort by a different column, or a new signup might land in the middle of an alphabetically sorted list. Comparing by row position would treat all of that as changes to every row after the shift. Matching by a stable key column instead means a row is recognized as "the same row" wherever it appears in either file, so only genuine differences are reported.

Reading the results

Each row in the output table is labeled added (its key appears only in the second file), removed (only in the first file) or changed (present in both, but with at least one differing field). For changed rows, the changed fields are listed as column: "old value" -> "new value", so you can see exactly what moved without diffing the whole row by hand. Rows with no differences aren't listed individually — they're rolled up into a single unchanged count, keeping the table focused on what's actually worth reviewing even for a large file.

Choosing the right key column

Pick a column whose value is unique per row and stable across both files — an internal ID, a SKU, an email address. If the chosen column isn't actually unique, multiple rows will collide on the same key and only the last one parsed will be compared, which can hide real differences. If your data doesn't have an obvious unique column, consider adding a row number or a composite key before comparing, or use the text diff tool for a line-by-line comparison instead.

The key column name must match a header in both files exactly, including capitalisation (id is not ID). If it is missing from either header, the tool tells you which file lacks it and lists the columns it did find. Only the Before and After files' shared columns are compared meaningfully: a column that exists on one side only is reported on changed rows as an empty value becoming the new value.

Limits

Each file is capped at 2 MB of CSV text, and parsing uses the same quoting rules as a standard spreadsheet export — quoted fields can safely contain the delimiter itself. If either file fails to parse, the tool reports the parser's exact error and the affected row.

Frequently asked questions

Is my CSV uploaded anywhere?
No. Parsing and comparison happen entirely in your browser; nothing is sent to a server.
Why do I need to choose a key column?
CSV rows can be reordered or have rows inserted between two exports of the same data — matching by a stable key (like id, sku or email) instead of row position is what makes the comparison accurate.
What happens to rows whose key only appears on one side?
They're reported as added (only in the second file) or removed (only in the first), rather than being matched incorrectly to a different row.
Are unchanged rows shown?
No — the table lists only rows that differ, and the unchanged count is reported separately so large files stay readable.