Join Two CSV Files by ID, Email, or Another Shared Column

Two CSV files can describe the same people, products, or transactions without containing the same columns. A join brings those columns together using a shared key.

That is different from appending files. Appending places rows underneath one another. Joining places fields beside one another when their keys match.

A small example

The first file contains programme records:

participant_id,name,site
P001,Ada Okafor,Muna
P002,Musa Bello,Custom House
P003,Aisha Umar,Muna

The second contains follow-up status:

participant_id,status,visit_date
P001,completed,2026-08-02
P003,pending,2026-08-04
P004,completed,2026-08-05

participant_id is the join key. P001 and P003 match. P002 exists only in the first file; P004 exists only in the second.

What the result should contain depends on the join type.

Choose the join deliberately

Inner join

Keeps only keys present in both files. In the example, the result contains P001 and P003.

Use it when the question is specifically about matched records. Do not use it merely because it produces a tidy-looking file: unmatched rows disappear.

Left join

Keeps every row from the first file and adds fields from the second where a match exists. P002 remains, with blank follow-up fields.

This is often the safest choice when the first file is the authoritative population and you need to see who has no matching follow-up.

Right join

Keeps every row from the second file. It is the mirror of a left join.

Unmatched-only result

Returns keys found on one side without a match on the other. This is useful for reconciliation, missing-record investigation, and checking whether two systems cover the same population.

Clean the keys before joining

A join compares values. It does not know that these should mean the same thing:

P001
p001
P001␠

Decide whether matching should ignore case and surrounding whitespace. Standardise both files the same way and retain the original key columns when auditability matters.

For email addresses, trimming whitespace and normalising the domain's case may be reasonable. Altering the local part, removing punctuation, or guessing aliases can create false matches.

For numeric-looking identifiers, preserve leading zeros. 00127 and 127 may identify different records, and Excel may already have damaged one file before the join begins.

Blank keys should not be treated as a shared identity. Several blank rows matching one another can create meaningless combinations.

Check whether the key is unique

Duplicate keys change the size of a join.

If P001 appears twice in the first file and three times in the second, a many-to-many join can produce six P001 rows. That is mathematically consistent, but it may be completely wrong for the business question.

Before joining, calculate for each file:

• number of data rows;
• number of non-blank keys;
• number of distinct keys; and
• keys appearing more than once.

If duplicates are legitimate, decide which relationship you are modelling. A participant may have several visits, for example. In that case, several joined rows may be expected. If one row per participant is required, aggregate or select the correct visit before joining.

Join the files in HappyCSV

Open Join CSV Files, upload the two source files, and choose the key column in each. The headings do not need to be identical as long as the selected values correspond.

Choose the join mode, process the files locally, and inspect the output before downloading it. Keep both source files unchanged.

When the files contain columns with the same heading other than the key, confirm how the result distinguishes them. A field named status may mean enrolment status in one system and visit status in another. Rename ambiguous columns before the join when possible.

Reconcile the result

Record these counts:

1. rows in the left file;
2. rows in the right file;
3. distinct non-blank keys on each side;
4. keys matched;
5. keys found only on the left;
6. keys found only on the right; and
7. rows in the joined output.

Then inspect samples from every category. A 98% match rate can still hide systematic failures if all unmatched rows come from one location or period.

For a left join with a unique key in the second file, the output should normally have the same number of rows as the left file. If it has more, investigate duplicate keys on the right.

Avoid fuzzy matching unless you can review it

Names are poor exact keys because spelling, order, spacing, and transliteration vary. Fuzzy matching can propose candidates, but it also creates false matches between different people with similar names.

Use a stable ID where available. If you must match on names, combine additional evidence such as date of birth, location, or telephone suffix, assign confidence levels, and review uncertain matches manually. Never present a fuzzy join as certain merely because software returned a result.

Keep an audit trail

Save the join settings, key-cleaning rules, source filenames, counts, and unmatched-key files. If the result informs payments, eligibility, reporting, or case management, someone should be able to reproduce it.

A join is trustworthy when you can explain both the matches and the records that did not match.