Combining two address books when the same people appear in both
Anyone who has run a small business, a club or a charity ends up with the same contacts scattered across a phone, a spreadsheet and whatever system the last person used. This article explains how to pull those exports into one list: how the three matching rules work and where each one fails, what the column mapping is really for, why a merge should keep the spare email addresses instead of binning them, and how to spot a suggested group that is quietly wrong.
The problem is not really duplicates
Ask someone what they need and they will say they want the duplicates removed. Watch what they actually do and it is something else. They open the second copy of a record, see a mobile number that the first copy does not have, and copy it across by hand before deleting anything.
That is merging, not deduplication, and the difference matters enormously. Deduplication picks a winner and throws the loser away. If the loser held the only mobile number you have for that person, you have just quietly destroyed data while feeling tidy about it.
So the goal here is not a shorter list. It is one record per person that holds everything you knew about them across every file, with the extra addresses and numbers kept rather than lost. The list gets shorter as a side effect.
Getting the files out of wherever they live
Two formats cover almost everything. CSV is what a spreadsheet, a CRM or a mailing platform gives you. vCard, usually a file ending in .vcf, is what a phone or a mail client gives you.
On an Android phone, the Contacts app has an export option that writes a .vcf file. On an iPhone the simplest route is to sign in to iCloud in a browser, open Contacts, select everything and export a vCard. Google Contacts offers vCard in its export menu. Outlook and Apple Contacts both have Export under the File menu.
For anything spreadsheet-shaped, ask for CSV. Mailing platforms all offer it. So does every CRM worth the name. If you only have an Excel file, save a copy as CSV first.
You can drop all of them onto the page together, and you can come back later and add one more. Files stack rather than replace, so a fourth export dropped in an hour later joins the list already there rather than wiping it.
Why the column mapping comes first
A CSV export has no fixed shape. One system writes a header row saying Name, Email, Phone. Another writes First Name, Surname, E-mail Address, Mobile Number. A third writes Phone 1 - Value and Phone 1 - Type because it was designed by someone thinking about databases.
None of that means anything to a computer until somebody says which column holds what. The page reads the header row and guesses, which handles most real exports, but the guess is only a guess and you can correct it.
Pick a file from the dropdown and you get one control per field: Full name, First name, Last name, Company, Job title, Email, Second email, Phone, Second phone, Address, Birthday, Website, Notes. Each one names the column it is reading, or says the field is not in this file.
Two traps show up often enough to mention. A column called Title sometimes means Sales Director and sometimes means Mrs, and the guess cannot tell which. And a column of work phone numbers labelled something unusual may land nowhere at all, in which case none of those numbers will ever match anything.
A line under the controls lists any columns that are not being used, which is the fastest way to notice that something important is being ignored. Fix the mapping before you start merging, because changing it afterwards throws away merges that were built on the old reading of the file.
Rule one: the same email address
This is the strongest evidence there is. Two records carrying the same address are almost always the same person, because an email address belongs to one mailbox by definition.
The only real complication is Google. Gmail ignores full stops in the part before the at sign, so firstname.surname and firstnamesurname arrive in the same inbox. It also treats anything after a plus sign as a label rather than part of the address, so a person who signed up somewhere as their own name plus a tag is using the same mailbox as always.
There is a setting to fold those two quirks together, and it is on by default. It applies only to Gmail and Googlemail addresses, because it is simply untrue elsewhere. Plenty of mail servers treat a full stop as a real character, and merging two people on that basis would be a genuine error rather than a clever catch.
Records with no email at all are not penalised. They just cannot be matched by this rule and have to rely on one of the other two.
Rule two: the same phone number, once it is normalised
Phone numbers are stored as text, and people type them however they like. The same landline can appear as 020 7946 0101, as +44 20 7946 0101, as 02079460101 and as (020) 7946-0101. Comparing those as strings finds nothing.
So every number is reduced to its digits, and then only the tail is compared. The default is the last nine digits, which is enough to be effectively unique within a country while surviving a missing or differently written international prefix.
You can change how many digits are used. Ten is stricter and works well for lists that are all from one country with consistent formatting. Seven is looser and helps with old records where an area code was dropped. There is also an option to compare every digit exactly as typed, which is the right choice if your list contains short internal extensions, because a four digit extension compared on its tail alone would collide with every other extension in the building.
One more thing worth knowing: a person's records only need one number in common to match. If the spreadsheet has a landline and a switchboard, and the phone export has the same landline and a mobile, the shared landline is enough.
Rule three: names that are merely similar
The first two rules are exact once tidied up. This one is a judgement, and it is the only one that can be wrong.
Before anything is compared, a name is stripped down. Accents come off, so an accented Spanish surname matches its unaccented twin. Punctuation goes, which handles an apostrophe in an Irish surname that one system kept and another dropped. Titles like Dr and Mrs are removed, and so are trailing bits like Jr and PhD. Finally the remaining words are sorted, so a record written surname first matches one written the usual way round.
What is left is compared word by word. Two words that differ by a letter or two score highly, which is what catches a surname with a silent final e in one file and not the other. A single letter is treated as an initial and scores well against a word starting with the same letter, so a record holding only an initial and a surname still recognises the full name. A name with extra words is penalised slightly, which stops a short name matching a longer one just because it is contained in it.
The result is a percentage, and the slider sets how high it has to be. Eighty-four is a reasonable starting point. Drop it and you catch more spelling variants along with more nonsense. Raise it and only near-identical names group, which is sometimes exactly what you want when a list is large.
The common name problem, and the guard for it
Fuzzy name matching has one predictable failure. In a list of any size there will be two different people with the same ordinary name, and no amount of cleverness in the scoring will separate them, because as far as the text is concerned they are identical.
There is a tick box for this: only treat a name match as evidence when the company matches too. Company names are compared after stripping the usual endings, so Alpha Ltd and Alpha Limited count as the same firm while Alpha and Beta do not.
With the guard on, two people who share a name but work in different places are left alone. It costs you the genuine merges where somebody changed jobs between exports, so it is not a free win. A sensible approach on a big list is to turn it on for the first pass, merge everything that survives, then turn it off and look at the handful of groups that appear.
How groups form, and why one can hold three records
The three rules produce pairs. Those pairs are then joined into groups, and joining is transitive: if the spreadsheet record and the phone record share an email, and the phone record and a third file share a number, all three end up in one group even though the first and third have nothing directly in common.
That is usually right, and it is how a person who exists in four systems ends up as one card rather than two pairs. It does mean a single bad pair can drag an unrelated record into an otherwise good group, which is worth watching for on lists where you have loosened the name threshold.
Each group tells you why it formed. A label reads same email address, same phone number, or similar name with the score. A group showing all three is about as certain as this gets. A group whose only reason is a name at seventy per cent deserves a proper look before you accept it.
Choosing what survives the merge
A group is laid out as a table. Every version of the person is a column, labelled with the file and row it came from, and every field is a row. Each cell has a button beside it, and pressing one says that this version of that field is the one to keep.
A suggestion is already selected when the group appears. For each field it picks the longest value that is not blank, on the reasoning that a longer value usually means more information: a full postal address rather than a town, a proper job title rather than a blank. It is a rule of thumb, not intelligence, and it is wrong often enough that the buttons are worth glancing over.
Emails and phone numbers behave differently, because for those the question is not which one wins. Every distinct address and number found anywhere in the group is listed with a tick box, and all of them are ticked. The first becomes the main one and the rest become Email 2, Phone 2 and so on. Untick anything you know is dead, such as a work address at a company the person left.
If a whole group is wrong, there is a button that says so. It rules that combination out permanently, so it will not reappear every time you change a setting. That matters more than it sounds on a long list, because the alternative is scrolling past the same wrong suggestion twenty times.
Undoing things
Two kinds of undo exist because two kinds of mistake happen.
The Undo button steps back through your merges one at a time. Merging every suggestion in one go counts as a single step, so one press puts the whole lot back if the results look wrong.
The other kind is noticing, twenty merges later, that one particular record is wrong. Every merged row in the final list has a button that splits just that one back into the records it came from, leaving everything else alone.
Removing a whole file is handled too. Any merge that depended on a record from that file is unpicked automatically, and the records from the other files come back as they were.
Getting the result out
CSV is the general-purpose answer. It opens in Excel, Google Sheets and Numbers. The columns grow to fit: if the most-merged person ended up with four email addresses, the file has four email columns and everyone else has blanks in the spare ones. Two extra columns at the end record which files each contact came from and how many records were folded together, which is useful if somebody later asks where a number came from.
One setting on the CSV is worth leaving alone. Excel assumes your computer's local character set unless the file begins with a small marker, and without it every accented name arrives mangled. The tick box that adds that marker is on by default, and no other program objects to it.
vCard is the answer when the list is going back into a phone or a mail client. Extra emails and numbers come across as additional entries on the same contact, exactly as they would if you had typed them in.
The printable sheet is deliberately plain: name, company, email, phone, in black on white. It exists for the times when what you actually need is a list on a clipboard rather than a file.
Formats that people argue about
Dates are the classic. A birthday written as 03/04 means the third of April to most of the world and the fourth of March to the United States, and neither side thinks their reading needs explaining. The birthday column can be written as a plain year-month-day date, day first, month first, or spelled out with the month named, which removes the ambiguity entirely. There is also an option to leave whatever was in the file untouched.
Exported vCards ignore that setting on purpose and always write the plain year-month-day form, because that is what the vCard format defines and anything else would import as the wrong day.
Phone numbers have a similar choice. You can leave them exactly as typed, reduce them to digits with a leading plus where the original was international, or have them grouped in threes for readability. Leaving them as typed is the safe default; the tidier forms are worth using when the list is going somewhere that will dial the numbers.
Working through a large list without losing your mind
On a few dozen contacts you can simply read every group. On several thousand you cannot, and trying will make you careless by the second screen.
The approach that works is to merge in passes of decreasing certainty. Start with name matching switched off entirely. What remains are groups that share an email address or a phone number, which are close to certain, and you can accept them in one go without reading them.
Then turn name matching on with a high threshold and the company guard active. Far fewer groups appear, and each one has real evidence behind it. Work through those.
Finally, if you still suspect there are overlaps hiding, lower the threshold and turn the guard off. This last pass will produce false suggestions, but there are few enough left that reading them is realistic, and the rule-out button keeps the wrong ones from coming back.
Name matching does not compare every name against every other name, because on a long list that is far too many comparisons. Names are grouped by their starting letters and only names sharing one are compared. That is fast and catches almost everything, at the cost of missing a typo in the very first letter of both the forename and the surname. On a very large list the comparisons stop after a set limit, and the page says so rather than pretending it looked at everything.
Where the data goes
It does not go anywhere. The files are read by your browser, the matching runs there, and the downloads are produced there. Nothing is sent to a server, and there is no account.
That is not a small point for this particular job. A contact export is names, phone numbers, email addresses and sometimes home addresses of real people, which in most of the world is personal data with rules attached to it. Uploading a customer list to a free website to tidy it up is the kind of thing that turns into an awkward conversation later.
Your work is kept in this browser between visits, so closing the tab halfway through a long merge does not lose it. It is stored only on this device, and the Start over button clears it completely.
If you want to check any of this, load the page, disconnect from the internet, and merge a file anyway. It will work, which is not something a tool that quietly uploaded your contacts could manage.