When is this useful?
Use it when one file has the event or transaction and another has the lookup data: orders + customers, inventory + product metadata, tickets + owners. It is the CSV equivalent of a simple lookup, without opening a spreadsheet first.
Pick the join by asking one question
LEFT keeps every A row, INNER keeps only keys found on both sides, and FULL also keeps keys that exist only in B. If you are unsure, start with “Do I need every row from A to survive?”
The B-side key itself is not duplicated into the output; A keeps the key column. Other non-key columns can still end up with the same header name on both sides, so check headers before sending the joined CSV into a system that requires unique column names.
Here is the easy-to-miss part: duplicate keys multiply rows
If A has two rows for key 42 and B has three rows for key 42, that key produces six output rows. The tool did not invent duplicates; it produced every matching combination. If the row count jumps, inspect key uniqueness on both sides first.
How keys are matched right now
Matching is exact. The tool does not trim spaces, normalize case, or coerce 001 into 1. Blank keys can also match other blank keys. That makes the behavior predictable, but it means cleanup should happen before the join when your keys are messy.
Because keys are not coerced to numbers, 00042 and 42 stay different. That protects code-like identifiers, but it also means padding differences must be normalized before the join if they are supposed to refer to the same entity.
A useful sanity check
If A has 100 rows and a LEFT JOIN returns 145, look for repeated keys in B. If an INNER JOIN collapses to 60 rows, many A keys may be missing from B. Row-count movement is often the fastest clue that the join is not shaped the way you expected.
Want the deeper explanation?