Sooner or later, the data you need lives in two files. One file holds customers and their identifiers; another holds cities and the same identifiers. One file holds orders; another holds the products in those orders. Combining them is called a join, and it is one of the most useful and most misused operations in data work. The wrong join type does not produce an error; it produces a plausible-looking file with the wrong rows in it, which is worse. The CSV Join and Merge Planner joins two CSV datasets on a shared column and previews inner and left joins, so you can see the row counts and the shape of the result before you commit to it.
A join works by matching values in a shared column, called the key. Each row in the first file, usually called the left file, is compared against rows in the second file, the right file, and rows whose keys match are combined into a single wider row. What differs between join types is what happens to rows that find no match. An inner join keeps only rows that match on both sides, discarding everything else. A left join keeps every row from the left file, filling the right-hand columns with blanks where no match exists. Those two behaviours sound similar in the abstract, but they produce different files, and the difference is exactly the rows you may or may not want to lose.
How the tool works
You provide two CSV datasets and choose the shared column, and the tool previews the joined result for inner and left joins. Everything runs in your browser, so the data never leaves your device. The planner framing matters: this is a tool for previewing and understanding a join, not for silently overwriting your files. You inspect the preview, check the row counts against what you expected, and only then use the result. That pause is where most join errors get caught, because the row count is the fastest diagnostic available. If you expected every left row to survive and the inner preview drops rows, the join type or the key is wrong, and the preview just told you so.
Choosing the key column is the most consequential decision in any join. The key must mean the same thing in both files. An identifier column in one file and a name column in the other are not the same key, even if some values happen to overlap. Keys should also be unique on at least one side for the result to be predictable. If both sides contain repeated keys, every matching pair combines, and the result can grow far larger than either input, a phenomenon known as a fan-out. A planner preview that shows an unexpectedly large row count is often the first sign of a fan-out.
A worked example
Take a left file with two rows: id 1 with name Ana, and id 2 with name Bo. Take a right file with one row: id 1 with city Oslo. Join on id. A left join keeps both left rows, giving 2 rows: Ana matched with Oslo, and Bo matched with a blank city, because no right row has id 2. An inner join keeps only rows that match on both sides, giving 1 row: Ana with Oslo. Bo disappears, because there is no city for id 2. Both results are correct under their own join type, and they answer different questions. The left join answers "every person, with their city where known". The inner join answers "only people whose city we know".
That distinction drives real decisions. A mailing list built from a left join includes everyone, with blanks you can handle. The same list built from an inner join silently excludes everyone without a match, and nobody notices until someone asks why a customer never received a message. Conversely, a report that should only cover matched records will be inflated with blank rows if a left join is used where an inner join was intended. Before you join, write down in one sentence which rows the result must contain, then pick the join type whose definition matches that sentence, and then check the preview's row count against it.
Common mistakes
The most common mistake is joining on a column that looks like a key but is not one. Names are the classic example: two different people can share a name, and one person can appear under two spellings, so a name join both merges strangers and splits individuals. Use a stable identifier whenever one exists. A second mistake is ignoring blanks in the key column. A blank key in one file will not match a blank key in the other in any sensible way, yet some tools treat blanks as matching, which merges unrelated rows. Check key columns for blanks before joining.
A third mistake is joining files with different key formats, such as an identifier stored as text in one file and as a number in the other, or with leading zeros in one file and without them in the other. The values look the same to a human and differ to a matcher. Normalise key formats first. A fourth mistake is not checking for fan-out. If the right file contains the same key twice, a left join will duplicate the left row, and a total that should have two rows can suddenly have three or more. The preview's row count is the warning; a count larger than the left file's row count means duplication happened somewhere.
Honest limitations
A planner previews joins on the data you provide; it cannot fix key problems, deduplicate your inputs, or know what your keys mean. It does not connect to databases or live systems, and it does not enforce uniqueness or referential rules. Very large files may be awkward to paste, and a preview is not a substitute for validating the final joined file, including checking for blanks where matches were expected and duplicates where they were not. The tool's value is in making the join visible before it becomes permanent, not in replacing the judgement about which join is right.
Closing
Before any join, state which rows the result must contain, pick the join type that matches that sentence, and check the preview's row count. The example to remember is small: left join keeps Bo with a blank city, inner join drops Bo entirely. One of those is what you want, and the other is a silent data loss. For neighbouring jobs, the JSON to CSV Converter and CSV Viewer and Editor help you prepare and inspect files before joining, while How to Turn CSV Data Into Useful Charts shows what to do with a cleanly joined dataset.