Diff two CSV files with the matching rule stated: a key that may repeat, or a real Myers diff, with every row accounted for
Initializing in your browser…
Combine CSV files with columns matched by name, so a reordered export still lands correctly, and every difference reported
Remove duplicate rows with equality as a stated choice: case, spaces, accents and numbers each their own switch, and the rule in force shown
View, sort and edit a CSV, with an undo stack that goes back exactly one step and a parse report that tells a broken quote from a ragged row
Two exports of the same member list. The second was written by a different system: the columns are in a different order, one member is new, one is gone, and one changed plan. A comparison that lines columns up by position and walks the rows index by index reports almost every row as changed.
Two files, keyed on id
before id,name,email,plan after id,plan,name,email
1,Alice,a@x.com,pro 0,trial,Zoe,z@x.com
2,Bob,b@x.com,free 1,pro,Alice,a@x.com
3,Carol,c@x.com,pro 2,pro,Bob ,b@x.com
4,Dave,d@x.com,free 3,pro,Carol,c@x.comResult
added 1 removed 1 modified 1 unchanged 2 added Zoe, id 0 removed Dave, id 4 modified Bob, plan free to pro and a trailing space on the name unchanged Alice and Carol Checked: all 4 rows of the first file and all 4 of the second are accounted for exactly once.
Columns are lined up by name, so the rearranged second file compares correctly. Alice and Carol are unchanged even though they moved. Bob is one modified row with two changed columns rather than four files worth of noise. The last line is the tool checking its own arithmetic: 1 removed plus 1 modified plus 2 unchanged is the 4 rows of the first file, and 1 added plus 1 modified plus 2 unchanged is the 4 of the second.
Compare two CSV files with both decisions stated: which row in the second file corresponds to which row in the first, and what counts as the same value. Every row of both files is accounted for exactly once, and the page checks that and says so, because a comparison whose numbers do not add up to the row counts has lost rows somewhere.
A diff tool is two decisions in a trenchcoat, and both of them are choices rather than facts.
**Which rows correspond.** With a key column, rows sharing a key are the same row wherever they sit in the file. When a key appears more than once the rows are paired in file order and the repeat is reported with its count in each file, because keeping one row per key and dropping the rest is how a comparison quietly loses data. An empty key is a key like any other and does not merge every keyless row into one. A key made of several columns is a structure, so a value holding a separator cannot collide with a different row.
Without a key, the match is a Myers diff, the algorithm behind git diff. That matters: walking two files index by index means a single row inserted at the top makes every row after it look modified, which is a wall of noise around one real change. A diff calls it one addition.
**Which columns line up.** By name when both files have a header, so the same columns in a different order compare correctly instead of comparing a name against a quantity, and a column that only one file has is named rather than shifting everything after it. Fields beyond what the header row names are still compared, so a row that gained a field is a change rather than a silent nothing.
**What counts as the same value.** Five independent switches: surrounding spaces, repeated spaces inside a value, case (folded in the Unicode sense, so the German sharp s matches ss), accents (so the two spellings of an accented letter match), and numbers (so 1, 1.0 and $1,000 against 1000 are the same value). With all of them off, two values are the same only when they are exactly the same text. Whichever combination is in force is written out in a sentence above the results.
The report downloads as a CSV rather than a text file, with one row per compared row and the before and after value side by side for every column, so it is something you can act on.
Compare the export before and after, keyed on the identifier, and read the modified rows with the changed columns highlighted.
A supplier sends a new file with the columns rearranged and one field added. Lining up by name shows the real changes instead of every row looking different.
The removed count and the row-accounting line together tell you whether anything went missing, which a comparison that silently keeps one row per key cannot.
Without a key, one new first row is reported as one addition and the rest as unchanged. Comparing index by index would have called every following row modified.
Two exports of the same table with the columns rearranged compare as unchanged, because the columns are lined up by name and the page says the order differed.
Three rows sharing an id are three rows. They are paired in file order and the page reports the key, with how many times it appears in each file.
The rows sharing a key are paired in file order and the repeat is reported, with how many times the key appears in each file. Nothing is dropped: the row-accounting line confirms every row of both files is counted exactly once.
Unchanged, if you are matching on a key, because the key finds it wherever it is. Positionally it is a removal and an addition, which is what a diff says about a move.
Yes, when both have a header row and the names are distinct. Columns are lined up by name and the page says the order differed. You can switch to lining them up by position if you want that instead.
Because by default two values are the same only when they are exactly the same text. Open "What counts as the same value" and turn on Ignore case; the sentence above the results updates to say what is in force.
Yes. A hundred thousand rows compare in well under a second in both modes, because the key match indexes each file once and the positional match is a Myers diff whose cost depends on how many edits there are rather than on how big the files are.
Rows and columns are parsed and transformed in memory in your browser. No record ever reaches a server.