What the CSV Join and Merge Planner does
This planner joins two CSV files on a key column - like a VLOOKUP or a SQL join - but shows you first what the join will do: how clean each key is, whether keys repeat, how many rows each join type will produce, and which rows will find no partner. Then it runs the merge in your browser and gives you the result as a CSV.
Most surprises in a merge come from the keys, not the join: a trailing space, a capital letter, a repeated ID. Seeing the counts before you merge is what stops a 5,000-row file quietly becoming 40,000 rows.
How to use it
- Add file A (the left side, usually the one you are enriching) and file B (the right side, usually the lookup). Drop, choose or paste each one; both stay in this tab.
- Choose the key column on each side. If both files share a column name, it is picked for you. Open the composite key section if one column is not enough, such as SKU plus warehouse.
- Tick Trim spaces or Ignore case if keys like
AB-102andab-102should count as the same. The findings tell you how many extra rows would match if you did. - Pick the join type and select Plan and merge. Read the findings and the row forecast for all four join types before downloading.
- Download the merged CSV, or the unmatched rows from either side to investigate them.
Reading the results
Inner keeps only rows whose key appears in both files. Left keeps every row of A and fills B's columns where there is a match. Right is the mirror image. Full keeps everything from both sides.
The relation describes the keys. One-to-one: no key repeats. Many-to-one: A repeats keys, B does not - the normal orders-to-customers case, and B's values are copied onto each A row. Many-to-many: both sides repeat a key, and every combination is produced; a key used 3 times in A and 4 times in B gives 12 rows.
The row counts are exact, not estimates: inner rows are the sum, over every key present in both files, of its count in A multiplied by its count in B. Left adds A's unmatched rows, right adds B's, full adds both.
Empty keys never match anything, following SQL, where NULL is not equal to NULL. They appear only in outer joins, as unmatched rows.
Worked example: orders joined to customers
The Orders + customers example has six orders (A) and four customers (B), joined on customer_id with a left join. Customer C01 has two orders, and C02 and C04 have one each, so the inner join gives 2 x 1 + 1 + 1 = 4 rows.
Two orders have no partner: one for C09, who is not in the customer file, and one with an empty customer ID. A left join keeps them with blank customer columns, giving 4 + 2 = 6 rows - the same as the number of orders, which is what a correct lookup should produce.
Customer C03 has no orders, so the right join gives 4 + 1 = 5 rows and the full join 4 + 2 + 1 = 7. The relation is many-to-one because only A repeats a key.
How the merged file is laid out
The output has all of A's columns in their original order, then B's columns except its key columns, which would only repeat A's. If B has a column with the same name as one in A, it is renamed with a (B) suffix rather than overwriting anything.
For rows that exist only in B (right and full joins), B's key is written into A's key column, so every output row still carries its key. Matched rows come first, in A's order; B-only rows follow in B's order.
Fixing keys before you merge
If the planner reports that trimming or ignoring case would match more rows, decide whether those differences are real. AB-100 and ab-100 are almost always the same product; two customer references that differ in case may not be, in a system that treats them as distinct.
Repeated keys on the lookup side usually mean the lookup is not what you think it is - several prices for one SKU from different suppliers, say. Pick the right row in the source, or add a second key column, rather than letting the join choose all of them.
Limitations: what the result does not prove
- It matches keys exactly as text, after the trimming and case options. It does not do fuzzy matching, so
Acme LtdandAcme Limitedstay different. - Leading zeros matter:
007and7are different keys. If one system dropped the zeros, fix that side first. - Each file is limited to 50 MB and 200,000 rows, and a merge that would produce more than 500,000 rows is refused with the forecast, so a many-to-many mistake cannot freeze the tab.
- The output is a new file. Nothing checks whether the joined values make sense together - only that the keys matched.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- RFC 4180 CSV - checked 19 Sep 2026
- OWASP CSV Injection - checked 19 Sep 2026
- PostgreSQL documentation - Joined tables
Frequently asked questions
How is this different from VLOOKUP in a spreadsheet?
VLOOKUP returns the first match and silently ignores the rest, so a repeated key gives you an arbitrary row. This planner shows repeated keys, produces every match explicitly, counts unmatched rows on both sides, and lets you choose inner, left, right or full joins.
Why did my merged file end up with more rows than file A?
Because some keys appear more than once in file B, so each A row with that key is repeated for every B match. The key quality table shows how many keys repeat and the largest repeat count; the findings flag many-to-many keys, which multiply fastest.
Can I join on two columns at once?
Yes. Open the composite key section and choose a second key column on each side. Rows match only when both values match, and a row with either key empty never matches.
What happens to rows whose key is blank?
They never match, in the same way SQL treats NULL. In an inner join they disappear; in left, right and full joins they are kept with the other side's columns empty. The findings tell you how many there are on each side.
Which file should be A and which should be B?
Put the file you want to keep whole on the left, as A, and the file you are looking values up in on the right, as B, then use a left join. The result then has one row per A row, as long as B's keys are unique.
Is the merged CSV safe to open in Excel?
Cells that begin with =, +, - or @ are written with a leading apostrophe so a spreadsheet shows them as text instead of running them as formulas. The file is UTF-8 with a byte-order mark, so accents, Arabic and emoji display correctly.
Last reviewed by the A2Z.Tools team against the sources listed above.
