To compare two lists for differences, paste one item per line into each box, choose whether letter case changes membership, and read off five stable views — common, A-only, B-only, union, and symmetric difference — without sorting the inputs. The Compare Two Lists tool treats every nonblank trimmed line as one set member: blank lines are dropped, duplicates collapse to the first displayed spelling, and the order you typed stays the order you read back. Each comparison runs locally in your browser, so neither list is uploaded, logged, or sent to any external service. The same normalized arrays that fill the visible panels also feed the labeled report you copy, which means a quick visual check matches what you paste into your destination system. The five operation names follow standard set terminology used in MDN's set methods reference and Python's built-in set types, so "union" or "symmetric difference" in a result panel means the same thing it would in code.
What the "Compare Two Lists" Task Actually Involves
Comparing two lists is the everyday job of saying which items show up in both lists and which ones appear in only one of them. The visible result has to be obvious: rows that share, rows that don't, and the combined shape of the two collections as a single set. The challenge is that everyday lists contain typos, mixed case, blank rows from a copy-and-paste, and stray duplicates, all of which change what should count as a single item. Treating the input as a set of membership keys and computing five named views is what makes the comparison reproducible and explainable.
The Compare Two Lists tool models each nonblank trimmed line as one member and applies your chosen case rule consistently across every panel. Because the same normalized arrays feed both the visible panels and the copied report, what you see is what you paste into your destination system. There is no hidden sort order and no silent reformatting step; the tool returns the result in the order members first appear, with first-spelling stability for duplicates.
Why five views instead of one difference list
A single "diff" answer rarely fits a single real task. Reconciling two email lists usually wants the union, but a migration check usually wants the symmetric difference, and a CSV cleanup usually wants A-only items separated from B-only items. Producing all five labeled views from one pass lets you grab whichever slice fits the downstream step without running the comparison again under a different rule.
The Five Set Views You Get in One Pass
The five labeled panels follow standard set terminology used in the JavaScript and Python standard libraries, so the same word means the same thing whether you read it in code or in a result panel.
| View label | Set meaning | Typical use |
|---|---|---|
| In both | Items present in List A and List B | Reconciliation, common inventory, overlap report |
| Only in A | Items in List A but absent from List B | Items that need to be added to B, A-only cleanup |
| Only in B | Items in List B but absent from List A | Items that need to be added to A, B-only cleanup |
| Union | All items in either or both lists, deduplicated | Merged record, combined membership, dedup report |
| Either not both | Items in exactly one list, not in both | Symmetric difference, gap analysis, migration check |
The ordering inside every panel follows the first-occurrence rule: A members appear in the order they were typed in List A, and any B members that did not already appear get appended in the order they were typed in List B. The tool never re-sorts results, which means your reading order matches your input order.
Worked example with two short lists
Take List A as apple, banana, pear and List B as banana, peach. The five views work out as:
- In both: banana — the only shared line.
- Only in A: apple, pear — both absent from B.
- Only in B: peach — absent from A.
- Union: apple, banana, pear, peach — every distinct line from both lists in first-occurrence order.
- Either not both: apple, pear, peach — A-only and B-only combined.
You can verify the symmetric difference manually by combining Only in A and Only in B, then confirming every line in that combined list is missing from exactly one input list.
Running the Comparison Step by Step
The whole job is a short, fixed procedure. Start with two plain-text lists where each item is on its own line, decide whether capitalization changes membership, then run the comparison and inspect each panel before copying anything downstream.
- Paste List A into the first box. One item per line. Avoid trailing commas or stray tabs at the end of each row — the tool will trim them, but cleaner input gives you a cleaner review.
- Paste List B into the second box. Same one-line-per-item rule. Keep the original order if first-spelling stability matters to you, because that order carries through into the result.
- Choose whether case changes membership. Pick case-insensitive for natural-language lists where Apple and apple should mean the same person, and pick case-sensitive for codes, identifiers, and passwords where casing carries meaning.
- Run Compare and read each labeled panel. Inspect In both, Only in A, Only in B, Union, and Either not both. The case policy you chose is applied consistently across all five.
- Copy the labeled report and verify against your destination. The clipboard write only happens after your browser confirms it; if your browser denies clipboard access, follow the manual-copy instruction instead of assuming success. Spot-check one or two lines in the destination system to confirm the literal line policy it expects matches the literal line policy you pasted.
The Case-Sensitivity Policy Decision
The choice between Apple matching apple and treating them as two distinct members is the single most consequential decision in the comparison, because it changes what counts as a duplicate key.
In case-insensitive mode, both inputs are normalized to English-lowercase membership keys while the first displayed spelling is kept verbatim. If Apple appears first in List A, that capital-A spelling shows up in the In both and Union panels even though the membership key is apple. In case-sensitive mode, the original capitalization is part of the key, so Apple and apple are reported as two separate lines and each appears in its own A-only or B-only slot if the other list lacks the same spelling.
Pick case-insensitive for human-facing collections — attendee names, email addresses, mailing lists, product labels — where a stray capital is just a typo. Pick case-sensitive for codes, URLs, environment names, file paths, and API keys, where capitalization carries semantic meaning. The tool is explicit that the selected policy applies consistently to deduplication and to all five operations, so you only have to make the call once.
Line Normalization Rules That Shape Your Results
Before any set arithmetic runs, the tool applies a fixed normalization pipeline to every line you paste. CRLF and standalone CR endings become LF, which means a list copied from Windows mail or a legacy script still compares cleanly against a list copied from a Unix paste. Surrounding whitespace is trimmed from each line, but whitespace inside the line is preserved exactly. Blank lines and whitespace-only lines are removed. Duplicate keys collapse to a single membership entry while keeping the first spelling typed.
These four rules — CRLF → LF, edge trim, blank drop, first-spelling dedup — together explain every "why did this line disappear?" surprise. A row that looks empty in a spreadsheet is treated as blank and dropped before deduplication even starts. A row like Apple is trimmed to Apple for membership purposes, and if the previously typed Apple already claimed that key in case-insensitive mode, the trimmed row is reported under the first spelling, not the trimmed one.
Order is also a deliberate part of the result: there is no sort. The Union panel reads in A's first-occurrence order with new B members appended, and every other panel follows the order in which members entered their respective lists. If your downstream system expects a sorted output, sort it after you copy the labeled report; do not assume the comparison will reorder anything.
When a List Comparison Is Not the Right Tool
The tool compares literal normalized line keys only. It is not a database join, a spreadsheet merger, a diff viewer, or a fuzzy deduplicator. It does not parse CSV columns, split commas, normalize Unicode confusables, or recognize equivalent domains and business identities. It does not compare numbers numerically, so 10 and 2 are two different string members, not two equal numbers. It carries no security access-control validation and no alias table, so treating a comparison as an allowlist decision is risky.
If your task needs any of those capabilities — matching near-miss spellings, joining on a column, sorting, recombining rows that were split by a delimiter — load your lists into a dedicated tool first and bring the cleaned line-per-item output back into the comparison. The same advice applies when your destination system has its own normalization rules: review the case policy and whitespace handling before treating any result as authoritative, because a downstream normalizer that lowercases everything will agree with case-insensitive mode here but a downstream normalizer that trims internal spaces will not.
Two final limits govern whether the comparison can complete at all. Each input is capped at one million UTF-16 code units and 50,000 lines; if either input exceeds either bound, the tool returns an explicit error and no partial results. If both normalized lists are empty, the tool returns the same explicit error rather than reporting a five-empty-panel result that could be mistaken for "no overlap found". Editing either textarea after a comparison clears the prior result, so the visible panels always reflect the most recent run against the most recent input.