Appending and joining answer different questions
Appending stacks two tables that describe the same kind of thing — January orders and February orders — and the result has as many rows as the two inputs together. Joining matches two tables that describe the same things from different angles — orders and their shipping status — and the result has one row per match. Picking the wrong one is obvious in hindsight and surprisingly easy in the moment, usually when the two files share a column name and stacking them looks like it worked.
In append mode, aligning by header name is on by default. Columns that exist on one side only are kept and filled with empty cells on the other, which is honest about the gap. Aligning by position instead is only safe when both files were produced by the same export, in the same order, and even then a single added column upstream silently shifts every value one place to the left.
The unmatched rows are the output that matters
A join that reports 400 rows tells you almost nothing. A join that reports 389 matched, 11 rows in A with no partner and 6 rows in B never used tells you where the data disagrees, and those 17 rows are usually the reason you ran the join. They get their own tables here, with the actual values, so you can see whether the mismatch is a trailing space, a lost leading zero, a genuinely missing record or a key that means two different things in the two systems.
| Symptom | Likely cause |
|---|---|
| Nothing matches at all | The key columns hold different things, or one side has been through a spreadsheet that stripped leading zeros |
| Some keys match, some do not | Whitespace, case, or a prefix that one system adds |
| More rows out than A had | Duplicate keys on the right, multiplying matched rows |
| Every key matches perfectly | Often both files are the same export under two names |
Duplicate keys multiply rows, and that is not a bug
If the key appears three times in B, each matching row of A comes out three times, once per partner. That is what a join does, it is correct, and it is also the single most common way a report ends up overstating a total. The count of extra rows caused by duplicate keys is reported above the result so the row count never surprises you afterwards. When you expected the right-hand side to be unique and it is not, deduplicate it before joining rather than after — the table cleaner collapses duplicates on selected columns.
Rows on either side with an empty key are never matched, including against each other. Two blanks are not evidence of the same thing, and treating them as a match is how unrelated records get stapled together.
Key comparison, and the leading-zero trap
Ignoring case and surrounding whitespace is on by default because most mismatches in real files are exactly that: AB-100 against ab-100 . Switch it off when the key is genuinely case-sensitive, which is true of many generated identifiers and of anything base64-shaped.
What no comparison setting can rescue is a key that has already been damaged. A postcode of 02134 that went through a spreadsheet as a number comes back as 2134 and will never match its partner. Nothing on this page converts your keys — they are compared as the text you pasted — but if one side was saved out of a spreadsheet, the damage happened before it got here. That is the argument for doing this kind of work in text tools rather than by opening the file and saving it again.
What is out of scope
One key column, no composite keys, no aggregation, no partial or fuzzy matching. For a composite key, build a single combined column on each side first — a batch find and replace or a spreadsheet formula will do it — and join on that. For comparing two plain lists rather than tables, list compare is the smaller and better fit, and once you have a joined table, CSV to SQL INSERT or the column profiler are the usual next steps. Do not paste customer, payroll or health records into any web page — this one included — without checking your own policy first; the processing here is local, but that policy question is separate from where the code runs.
Questions people ask
Which join type should I use?
Keep every row of A when A is your working list and B is a lookup you are enriching it with — you want the gaps visible, not the rows gone. Use matched rows only when the point is the intersection and unmatched rows are noise. Use everything from both sides when the two files are meant to be the same population and you are reconciling them; that mode puts the orphan rows from B underneath with their A columns blank apart from the key.
Why are there more rows in the result than in table A?
The key repeats in table B. Each duplicate produces another matching row, so a key appearing three times on the right turns one row on the left into three. The extra-row count is reported above the result. If B was supposed to be one row per key, deduplicate it before joining — otherwise any total computed from the joined table will be inflated by exactly that many rows.
Can I join on two columns at once?
Not directly. Make a single combined key on each side first, for example by concatenating the date and the store code into one new column with a separator that cannot appear in either value, then join on that. Doing the combination in the source system or a spreadsheet is usually a one-formula job, and it makes the join both possible and easy to audit afterwards.
Do the two tables need the same delimiter?
Yes. One delimiter setting is applied to both boxes, and it is detected from table A when left on automatic. If the two pastes use different separators, convert one of them with the delimiter and quoting fixer first. Both tables must have a header row, since the key is named rather than positional and the output header comes from the two inputs.
Are the unmatched rows included in the copy box?
That depends on the mode. Keeping every row of A includes the unmatched A rows with the B columns blank; matched-only excludes them; everything-from-both-sides includes the orphans from each side. The tables listing unmatched rows below the result are always shown, whichever mode you picked, and they are capped at 25 rows on screen for speed.