Free browser tool

CSV key join

Join two CSV datasets by key using INNER, LEFT, or FULL join and export the result.

Input and settings

How to use

You have order totals in one CSV and customer names in another. The shared customer_id should connect them—but a join can also multiply rows if the key is duplicated. This tool joins two CSVs while making the output row count easy to check.

  1. Paste CSV A and CSV B, then choose the key column in each file.
  2. Choose LEFT, INNER, or FULL depending on which unmatched rows you want to keep.
  3. Check the output row count before downloading. A surprising increase usually means duplicate keys.

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?