GedMend › Guides

How to merge two GEDCOM files without creating duplicates

Combining a received family file with your own is one of the fastest ways to damage years of research. Here is the method that keeps it safe, and the check that catches what a merge silently drops.

Last updated 1 September 2026

Why a merge goes wrong

A GEDCOM you receive from a cousin, a research society, or an online export almost always overlaps your own tree. The overlap is the problem. Six failures account for nearly all the damage, and five of them are silent:

• Duplicates that were never noticed. Your John Smith and their Jno. Smith are one man. A tool that compares strings exactly will import a second copy of him, with half his family attached to each.
• Duplicates that were wrongly fused. The opposite mistake, and the worse one. Two genuinely different men called John Smith, both born in Leeds around 1834, look nearly identical to any matching algorithm. Fusing them corrupts two lines at once.
• Facts overwritten without asking. You spent a month establishing a birth year of 1834. Their file says 1836. Many merges simply take one.
• Source citations dropped. A merge that keeps the date and discards the parish register has kept the rumour and thrown away the proof: the date is still there, and you can no longer show why you believe it. (More on citations.)
• Accented names garbled. If the two files store text differently, Müller can arrive as Mÿller or Mller. This one is at least visible — but only if you go and look.
• Broken family links. A parent pointer aimed at a record that no longer exists, or at the wrong one.

What makes all of this expensive is where it happens. A merge performed inside your main genealogy program writes into your master tree. There is often no undo, and even where there is, you will not know to use it: the damage is quiet by nature. You will find it in three years, in a branch you had not looked at since.

The method

1. Copy both files before you touch anything

Take a fresh GEDCOM export of your master tree and put it, plus the incoming file, in a new folder with today's date. Work only on those. Whatever else happens, the tree in your genealogy program is untouched and you can walk away at any point.

2. Look at both files before comparing them

Two things are worth knowing up front. How many records each file holds — a file with 300 people and a file with 12,000 are not a merge, they are an import. And how each file stores its text, because that determines whether accented names survive. If the two disagree, that is worth resolving before anything else; the accented names guide covers what to look at.

3. Find the people who appear in both — and confirm each one yourself

This is the step that decides whether the merge is safe, and it is the step most likely to be automated away. A good candidate list gets you most of the way; a candidate list is not a decision.

Judge each proposed pair on the things a score cannot settle — GedMend's included. Every scoring scheme is good at surface similarity and bad at the judgement that resolves an ambiguous case, which is the whole argument for confirming each match yourself:

• Family context beats name similarity. Two John Smiths with the same wife and the same three children are the same man. Two John Smiths with no relatives in common usually are not, however well the dates line up.
• A high score is not a probability. It means the records look alike. In a parish where four generations shared six forenames, records looking alike is the normal condition.
• The interesting cases are in the middle. The strong matches are obvious and the weak ones are noise. The same woman recorded under a nickname with a wrong decade sits somewhere in between, and she is exactly the one you will miss if you only skim the top of the list.
• Undecided is a legitimate answer. Anything you are not sure of should be left as two records. A duplicate you can see is a nuisance. A wrong fusion is a corruption.

4. Resolve disagreements one at a time

Where the two files hold different values for the same fact, you want to see them side by side and choose — yours, theirs, both, or a corrected third value. Two rules make this faster than it sounds. Facts that appear in only one of the two files need no decision at all; they simply carry over. And choosing between two values is not a choice between two sources: keeping your birth year should not discard their evidence for theirs. The value is a decision; the citations are kept regardless.

5. Check the arithmetic before you write anything

There is one equation. It is not your arithmetic — it is an audit of the tool, and it catches an entire category of failure while being blind to another:

people in file A + people in file B − pairs you confirmed as the same
    = people in the merged file

Every confirmed pair removes exactly one duplicate, so it must come out exactly. If it does not, something has been dropped or invented, and you want to know that before the file exists rather than after you have imported it. Run the same check for families.

Nobody miscalculates this, and the point is not that you might. The failure it catches is a merge quietly losing three hundred people, or inventing them, with nobody going to look — which is worth demanding a number for before you let software write a file. It earns being spelled out for a second reason: when the counts have to be read out of two different programs and compared by hand, it is a chore, and a chore is the step people skip. What the equation cannot tell you is whether the people who survived are the right ones. A correct count with wrong contents passes it; step 7 is the check for that.

6. Export to a new file, and keep a record of what you decided

The output should be a new file with a new name. Neither original should be modified by the process at any point — if a tool wants to write to your input files, that is a reason to stop.

Keep a written report of every match you confirmed, every field decision, and which citations were carried across. In a year, when you wonder why a birth year reads 1834 and not 1836, that report is the only thing that can tell you — and, importantly, whether the answer was your decision or a default.

7. Import the result and look at the merged people

Import the new file as a new tree, not over the top of your master. Then go and look at fifteen or twenty of the people you merged — their dates, their families, their sources. If those are right, the rest almost certainly is. Only then does the merged tree become your working tree.

What not to do

• Do not import a received GEDCOM straight into your master tree and plan to clean up afterwards. The cleanup is harder than the merge, and by then the two trees are indistinguishable.
• Do not accept bulk matching above a threshold. A threshold is a way of ordering your reading, not a way of skipping it.
• Do not merge three files at once. Do them in pairs. Every additional file multiplies the number of judgements and destroys your ability to attribute a mistake to a source.
• Do not delete the originals when you are done. They cost nothing to keep and they are the only way back.