Compare Two Lists
Find what's only in A, only in B, and in both — in your browser, nothing uploaded.
Nothing you paste is uploaded — the two lists are compared entirely in this browser, so it can be used without a security review.
List A
Or drop a CSV/TXT file —
List B
Or drop a CSV/TXT file —
Matching options
Options change matching only — your original text is always kept for display and export.
Paste or drop two lists above — or load the sample — to see what is only in A, only in B, and in both.
Reading two lists as sets, not just text
Comparing two lists sounds trivial until the lists are real: a 640-row event registration export against a 615-row payment log, or last month's CRM contact export against this month's. Manually scrolling for mismatches stops working past a few dozen rows, and copy-paste eyeballing tends to miss exactly the cases that matter — near-duplicate spellings, trailing whitespace, a header row accidentally counted as data. This tool treats each list as a mathematical set and computes the four relationships that answer almost every "did these two things line up" question: what is only in A, what is only in B, what is in both, and what the combined total looks like.
How to use it
- Paste or drop List A and List B — one item per line, or a raw CSV/TSV export.
- If a file has more than one column, a preview and column picker appear; choose which column is the comparison key (for example "email" or "order ID") for each side independently.
- Pick a country preset, or leave it on International, to switch on the text-normalization rules that fit your data.
- Read the four result tabs — Only in A, Only in B, In both, Union — and copy or download any of them as CSV.
The set logic
Let A and B be the two lists after normalization. The tool computes four values from them:
A − B (Only in A) — items in A with no match in B
B − A (Only in B) — items in B with no match in A
A ∩ B (In both) — items present in both lists
A ∪ B (Union) — every distinct item from either list, counted once
A useful sanity check on any run: |A − B| + |B − A| + |A ∩ B| should equal |A ∪ B|. If the counts don't add up, a duplicate inside one list — not between the two — is usually the cause; the union collapses it but the A-only/B-only counts don't.
Worked example 1 — event check-in reconciliation
List A (RSVPs, 6 names): Kim, Lee, Park, Choi, Jung, Han.
List B (checked in, 5 names): Lee, Park, Choi, Jung, Song.
Only in A: Kim, Han — RSVP'd but never checked in.
Only in B: Song — checked in without an RSVP (a walk-in).
In both: Lee, Park, Choi, Jung.
Union: 7 people touched the event in some way — 2 + 1 + 4 = 7.
Worked example 2 — SKU inventory audit
The warehouse system lists 1,204 SKUs. The sales platform lists 1,187 SKUs.
After comparing: 22 SKUs are only in the warehouse (discontinued but never delisted online), 5 SKUs are only on the sales platform (listed but never received), and 1,182 SKUs match.
Check: 22 + 5 + 1,182 = 1,209 = the union. The warehouse team now has an exact 22-item delist queue instead of a guess.
Worked example 3 — a Korean name list with a hidden mismatch
List A has "홍 길동" (with a space). List B has "홍길동" (no space). A plain text compare puts both in the "only in" columns even though they refer to the same person — the single most common false mismatch when reconciling Korean or Japanese name lists.
Turning on the Korea preset (which enables "Remove all spaces" plus NFC normalization) merges them into the intersection instead, without changing how the names are displayed or exported.
Normalization options at a glance
| Option | Fixes | Example |
|---|---|---|
| Trim & collapse spaces | Leading/trailing/double spaces from Excel copies | " Kim " → "Kim" |
| Remove all spaces | Spaced vs. unspaced names | "홍 길동" = "홍길동" |
| Ignore case | Capitalization differences | "Alice" = "alice" |
| NFC | Decomposed vs. composed Hangul jamo | matches regardless of which IME typed it |
| NFKC | Fullwidth vs. halfwidth characters | "ＡＢＣ" = "ABC" |
| Ignore accents | Diacritic variants | "café" = "cafe" |
| Turkish-safe case | Dotless ı / dotted İ | "İstanbul" lowercased without corruption |
| Ignore leading zeros | Zero-padded IDs | "00123" = "123" |
Common mistakes
- Assuming every mismatch is an error, when it is often a naming-convention gap — surname-first vs. given-name-first entries look identical to a human but not to a plain string compare.
- Forgetting to tick "First row is a header," which lets a column title get compared as if it were real data.
- Turning on every normalization option at once — over-normalizing can merge two genuinely different items, such as accent-folding "Peña" onto "Pena" when a dataset actually contains both as distinct people.
- Comparing whole CSV rows instead of a single key column — one extra trailing field makes otherwise-identical rows look different.
Limitations
The tool matches on text after normalization — it cannot infer that "Bob Smith" and "Robert Smith" are the same person, and it will not reorder "Gil-dong Hong" into "Hong Gil-dong" for you. For reordered names, split the name into separate columns and compare the surname column on its own. This is built for exact-after-normalization matching, not fuzzy or approximate matching, and it does not perform record linkage across differently structured datasets.
Sources & further reading
Frequently asked questions
Is my list sent to a server, and why can I use this without security approval?
No. This list comparison tool runs 100% in your browser — the two lists you paste or drop are parsed, normalized and compared with JavaScript on your own machine, and nothing is uploaded, logged or stored on any server. There is no account and no network request carrying your data. That is exactly why teams that handle names, member IDs or customer lists can compare two lists here even when an upload-based SaaS would fail a security review: the data never leaves the tab. Close the tab and the lists are gone; only your matching options and column choices are remembered in this browser's local storage.
Why are "홍 길동" and "홍길동" treated as different, and what does "remove all spaces" do?
By default a plain text compare treats "홍 길동" (with a space) and "홍길동" (without) as two different strings, so they land in A-only and B-only instead of the intersection — the single most common false mismatch when reconciling Korean or Japanese name lists. That is why the "Remove all spaces" option is on in the Korea and Japan presets: it strips every space from the matching key so spaced and unspaced names line up. It changes matching only — your original spelling is preserved for display and CSV export. Combined with "Trim & collapse spaces", it also fixes stray leading, trailing and double spaces that Excel copies often leave behind.
What is the difference between A-only, B-only, intersection and union, and when do I use each?
The tool shows all four sets at once so you can find differences between two lists in a single pass. A-only (A minus B) is everyone in A who is missing from B — attendees who did not pay, items ordered but not received. B-only (B minus A) is the reverse — payments with no matching attendee, receipts with no order. The intersection (A and B) is what appears in both — the matched, reconciled rows. The union is every distinct item across both lists combined, with no duplicates. For a reconciliation you usually watch A-only and B-only (the exceptions); the intersection and difference of lists together must add up to the union, which is a quick sanity check on the counts.
How do I compare just one column from two CSV files?
Paste or drop each file into its own box. When a list has more than one column, the tool auto-detects the delimiter (comma, semicolon, tab or pipe), shows a preview, and lets you pick the "Compare by column" for each side independently — so you can match column C of one export against column A of another. Tick "First row is a header" if the top row holds column names; it is left out of the comparison. Everything else in the row is ignored for matching but the chosen cell is what you export. This makes list diff online practical for real spreadsheet exports, not just clean one-item-per-line lists.
How does it handle country-specific name spelling — surname order, fullwidth characters and accents?
Pick the country preset that matches your data and the right normalization rules switch on. Korea uses NFC so decomposed and composed Hangul jamo match, plus space removal. Japan and China add NFKC so fullwidth ＡＢＣ and halfwidth ABC (and fullwidth digits) are treated as equal. Europe adds accent folding so café and cafe match. Türkiye uses a Turkish-safe lowercase so the dotless ı and dotted İ are not mangled by a naive lowercase. What the tool cannot know is field order: if one list writes "Gil-dong Hong" and the other "Hong Gil-dong", split the name into columns and compare the surname column, because reordering words automatically would create false matches. For 명단 비교 in practice, remove-spaces plus NFC clears the large majority of mismatches.