Compare Two CSV Files

In short: RowSlice's CSV compare tool reads two CSV files in your browser and reports what moved between them: how many rows were added, removed, changed and left alone, which columns changed — with the value before and after — for up to 100 of the changed rows, and which columns exist in only one of the files. Rows are matched on a key column you choose — a customer ID, an email address, a SKU — so the two files can be sorted differently and still line up. The added, removed and changed rows are written to separate CSV files. It is not a line-by-line text diff, and it does not merge the two files or decide which version of a row is correct: it reports what is different and leaves both of your files untouched. Nothing is uploaded.

How to Compare Two CSV Files

1. Choose or drag in both files, the older one first; if they go in the wrong way round, Swap Old and New puts them right. They are read from your disk instead of uploaded, so even a multi-gigabyte pair is ready in a second.
2. Choose the column that identifies a record — customer_id, email, an order number, a SKU. Tick more than one if it takes a combination to identify a row.
3. Leave every shared column in the comparison, or name the columns to compare when some of them are rewritten on every export.
4. Press Compare Files, read the counts, and download whichever of the result files you need.

What Added, Removed, Changed and Unchanged Mean

Every row of both files lands in exactly one of four buckets, and its key decides which. Take an inventory export run in March and again in April, matched on sku:

A row is added when its key is in the new file and nowhere in the old one, and removed when its key is in the old file and never turns up in the new one. A key found in both files gives a changed row when at least one compared value differs, and an unchanged row when every compared value is identical, character for character, after whatever ignore-case and ignore-spaces rules you asked for.

Unchanged rows are counted and nothing more: they are already sitting in both of your files, so writing them out a third time would only make the results harder to read. Everything else becomes a file, named after the file it came from — for inventory-march.csv and inventory-april.csv:

A file is written only when it has rows in it, so a run where nothing was removed gives you no removed file at all and the download list is itself part of the answer. On screen you also get the changed rows in detail — the key, the column that changed, the value before and the value after — for up to 100 of them. That list is capped because it is the one part of the run that keeps values in memory; the downloaded files hold every changed row, however many there are. When there are more of them than a spreadsheet will open, open that file in the CSV viewer, which pages through a CSV of any size and can search it for one key.

Neither of your files is modified, and no file combining the two is produced. If what you want is the rows of both files in one file, that is a different job: merge the two CSVs and, when the same record is then in there twice, remove the duplicate rows afterwards.

Choosing the Key Column

The whole result rests on the key. It is how a row in one file is recognised as the same record in the other, and a key chosen badly does not give a slightly worse answer — it gives a confident wrong one, usually a report in which almost everything was removed and almost everything was added.

A key column needs two properties, and both are worth checking rather than assuming:

• Unique within each file. One row per key, in the old file and in the new one.
• Stable between the two exports. The value has to survive whatever happened in between. A database ID normally does; a row number, a line position or a sequence the export regenerates on every run does not, and matching on one of those compares row 5,000 with row 5,000 rather than a record with itself.

When no single column is unique, tick several and their values are joined into one key — store_id plus sku, or first name plus last name plus date of birth. Keep the key as short as you can. A column that is part of the key is not a column whose changes get reported: change it and you get a removed row and an added row instead, which is the correct answer to the question that was asked and rarely the one you wanted.

Ignore upper and lower case and Ignore spaces at the start and end of values apply to the key as well as to the values being compared, which is usually what you want for data typed by people. Without them, ANN@SHOP.COM and ann@shop.com are two different keys, so one record is reported as removed and added rather than matched.

If the same key appears more than once in a file, the comparison is ambiguous: there is no way to know which copy belongs with which. The tool keeps the first row for each key, counts the rest and shows you that count. Treat anything above zero as a caution on the whole report. You can check a column before you start — the CSV analyzer gives the number of distinct values in every column next to the number of data rows, and a column where those two numbers are equal is unique — and Remove Duplicates from CSV collapses the repeats when they really are the same record twice.

When the Two Files Have Different Columns

Two exports of the same thing, taken months apart, are rarely identical in shape. A column gets added, two swap places after an upgrade, one is renamed. Columns are therefore lined up by header name, compared after removing spaces from the ends, so email and email are the same column and the order they appear in does not matter. Where a header name is missing, or the files have no header row, the columns are lined up by position instead.

Columns that do not line up are named in the report, in two lists: those found only in the old file, and those found only in the new one. Those columns take no part in the comparison, because there is nothing on the other side to compare them with. The practical effects are worth knowing in advance:

• Adding a column to this month's export does not mark every row as changed. The new column is listed as being only in the new file, and the rows are judged on the columns the two files share.
• A column that disappeared is not reported against any row either. It is a change to the file rather than to a record, and the report names it once, in the list of columns found only in the old file.
• A renamed column looks like both at once: postcode appears under the old file's list and postal_code under the new file's, and the values in them are never compared. Rename one of them to match the other before comparing if you want changes in that column reported.

Reading those two lists first is the quickest check on whether you have the pair of files you think you have. When the only-in lists are long, the two files are usually different reports rather than two runs of one report. Merging CSV files with different columns or headers works through the same header drift from the other side of the problem, including how a renamed column gives itself away.

Comparing Only Some Columns

Plenty of exports carry a column that is rewritten every time they run: last_modified, exported_at, a batch or job number, a sequence generated fresh. Compare everything and every row comes back changed, which is true and useless. Name the columns you actually care about instead, and the rest are ignored when deciding whether a row changed.

It works the same way when the question is narrower than the file. To find out which prices moved between two price lists, compare the price column only: a row whose description was reworded stays unchanged, and the changed list is the one you came for. Two things to keep in mind. The columns you left out may well have changed — the report says nothing about them, and a row reported as unchanged is unchanged in the columns you named. And the files you download hold complete rows rather than only the compared columns, so a changed row arrives with all of its values.

Why Not VLOOKUP or a Spreadsheet?

For a few hundred rows in files that open without complaint, a spreadsheet is a reasonable answer and has one real advantage: you can see the rows. VLOOKUP, or XLOOKUP in newer versions, pulls last month's value in beside this month's, and for a one-off check of one column that is the end of it.

It stops being reasonable in three specific places:

• Size. Both files have to fit on a sheet, so each is capped at 1,048,576 rows, and a lookup formula on every row of a file anywhere near that size is slow enough to become its own problem.
• A lookup does not give you the four answers. It puts the old value next to the new one. Turning that into added, removed, changed and unchanged means wrapping it in IFERROR, running a second lookup in the other direction to catch the rows that disappeared, and repeating the whole arrangement for every column you want to check.
• The values change as the file opens. Excel reads 00742 as the number 742, so the leading zeros are gone, and it keeps only the first 15 significant digits of a number, so a 16-digit account or transaction number arrives rounded and shown as something like 4.5E+15. A code such as MAR-1 is read as a date. That is fatal for a comparison, because keys are very often exactly those kinds of value: 00123 and 123 become one key, so a removed record and an added record appear as a single matched row, and two long IDs that agree in their first 15 digits become one row as well.

RowSlice reads the raw text of both files and compares text, never interpreting it, so 00123 and 123 stay two different keys and a long ID keeps every digit. Both files stream past 4 MB at a time instead of being loaded, so they can be far longer than a spreadsheet would open, and neither of them leaves your computer. What it will not do is show you the file: beyond the preview and the sample of changed rows, the answer arrives as counts and as CSV files you open elsewhere. If those files are going to somebody who works in Excel, write them out as .xlsx rather than opening the CSV in Excel, which would round the long IDs the comparison was careful to keep.

Last updated September 22, 2026.