Duplicate Individuals: How They Happen and How to Find Them

Duplicate individuals — the same real person appearing as two or more separate records in a GEDCOM file, each with its own ID — are one of the most common data-quality problems in family trees, and also one of the hardest to catch. Unlike a broken link or a dangling reference, nothing about a duplicate record is structurally wrong. Each copy parses fine, has valid tags, and points to valid families. The only way to know it's a duplicate is to notice that two different @I%@ records describe the same person.

How duplicates get into a tree

The most common cause is combining research from multiple people. If you and a cousin have each independently researched the same great-grandparent in separate programs, then merge your two files together, that person now exists twice — once from each source — usually with slightly different spellings, dates, or amounts of detail. Repeated imports cause the same problem on a smaller scale: importing an updated GEDCOM export into a tree that already contains an earlier version of the same data, without the software recognizing the overlap, produces a second copy of everyone who was already there. A third cause is manual re-entry — someone adds a person by hand because a search didn't find the existing record, often because a name was spelled differently or a middle name was omitted.

Why this is a fundamentally different problem than the Validator solves

The Validator checks things a computer can verify with certainty from the file's structure: does this pointer resolve to a real record, does this date come before that date, is this link reciprocated. Duplicate detection isn't that kind of problem — it requires judgment calls about similarity ("John Smith b. 1850" and "Jon Smith b. abt 1851" might be the same person or might not), and a tool that guesses wrong in either direction causes real harm: merge two different people and you corrupt both of their histories, or flag thousands of false positives and the tool becomes useless. Purpose-built fuzzy-matching tools exist specifically to handle that trade-off with configurable confidence thresholds — this site doesn't attempt to replicate that.

A practical manual workflow

For a tree small enough to review by eye — a few hundred individuals — the most effective approach is sorting, not searching. Export your file with the Excel converter or CSV converter, which lists every individual with their resolved name, birth date, birth place, and parents in one row each. Sort the spreadsheet by surname, then by birth year within each surname group. Duplicates cluster together once sorted this way, since near-identical names and years land on adjacent rows where they're easy to spot by scanning down the list, rather than being scattered across the file in whatever order the original software wrote them.

What to look for once you've found a candidate pair

Two records are very likely the same person if the surname matches (allowing for a plausible spelling variant), the birth year is within a year or two, and the birth place agrees or one record simply has it blank. Parents matching is the strongest confirming signal — if both records list the same father and mother, or one record's parents are a subset of the other's, that's close to conclusive. Records that only share a common name but disagree on birth year by a decade or more, or list different parents, are more likely to be two different relatives than a duplicate — don't merge on name alone.

Before you merge

Whatever software you use to actually perform the merge, back up your file first — merging is one of the few operations in genealogy software that's genuinely hard to undo cleanly once sources, notes, and media attached to both copies get combined. If you're working from a file inherited from someone else and suspect it's accumulated several rounds of duplicates over the years, see Cleaning Up a GEDCOM Inherited From a Relative for a broader first-pass workflow before tackling duplicates specifically.