--- title: How to find and merge duplicate people in a GEDCOM slug: find-and-merge-duplicate-people-in-a-gedcom description: Review duplicate candidates and their evidence, merge confirmed pairs, and export the decisions and undo data. Keep a pre-merge backup. tools: [duplicate-finder, merge-arbitration, merge-workbench, determination-ledger] difficulty: intermediate time: 30 minutes lastChecked: 2026-09-06 published: 2026-09-02T23:15:28+02:00 --- # How to find and merge duplicate people in a GEDCOM Your great-grandmother is in the tree twice. One copy came from a cousin's GEDCOM, one you typed yourself, and they spell her surname differently. Multiply that by every import you have ever made. You want the duplicates found, and you want to be able to undo any merge you get wrong. ## What causes it Duplicates arrive four ways, and each leaves a different fingerprint. **Two imports of overlapping trees.** The same person appears under two xrefs with slightly different dates. Names match, dates are close, places match. **A one-way family link.** A `FAM` record lists `WIFE @I47@` while `@I49@` claims `FAMS @F17@` without a matching link. This can indicate a duplicate or a wrong relationship. A probable-duplicate reciprocity finding carries +0.45, the largest positive weight in this scorer. It does not prove identity. **Transliteration.** `Телешкевич` and `Teleszkiewicz` can represent the same surname in different scripts and spelling conventions. An exact string comparison misses that possible relationship; shared spelling or transliteration still does not prove personal identity. **Someone typed the person again** because search did not find the first copy. There is another pattern to investigate: two children of the same parents carrying the same given name, because the first one may have died. Read [how to tell a duplicate from a child named after a dead sibling](/how-to/tell-a-duplicate-from-a-child-named-after-a-dead-sibling). The finder can assign a `necronym` verdict alongside the numeric score. ## Where a pair goes ```mermaid flowchart TD PAIR["A candidate pair"] --> N{"Same parents and the same given name?"} N -- "yes" --> NEC{"Can the two lives have been sequential?"} NEC -- "yes" --> V3["Verdict: necronym. Merge is not offered"] NEC -- "no, the birth dates overlap" --> SC["Score the pair"] N -- "no" --> SC SC --> T{"Score at or above the threshold slider?"} T -- "yes" --> V1["Verdict: merge candidate"] T -- "no, and at or above 0.30" --> V2["Verdict: below threshold, hidden until you ask"] V1 --> A{"Are you sure?"} A -- "yes" --> W["Merge Workbench: review fields and preserve a backup"] A -- "not sure" --> ARB["Merge Conflict Arbitration: both sides argued"] A -- "no" --> DIS["Dismiss: writes merge-rejected into the file"] V3 --> DIS ARB --> W ARB --> DIS DIS --> EX["Build and download the determination GEDCOM; reload it before the next tool"] W --> MX["Download merged GEDCOM; reload it before the next tool"] ``` ## The fix 1. Keep an untouched backup, then open [Duplicate Individual Finder](/duplicate-finder) and drop a working copy. Read the people, family, candidate-pair and scored-pair counts under the heading. 2. Read the three counts: `merge candidates`, `necronyms`, `below threshold`. 3. Work the merge candidates from the top. Each pair shows both records side by side with name, xref, line, sex, birth, death, places, parents, spouses and children, then a table with three columns: Weight, Signal, What it compared. The scorer sums the weights and clamps the result to 0 through 1. 4. Read the signal table before the score. `surname match +0.25`, `given name match +0.20`, `birth same-year +0.20` and `birth place match +0.10` sum to 0.75. These signals can come from the same copied source; they are not independent evidence or a 75% probability of identity. Compare citations and conflicting relationships before merging. ![A merge candidate in the Duplicate Individual Finder at score 0.40: two records side by side, then a signal table reading surname match +0.25, given name match +0.20, birth apart -0.10, death far -0.20 and shared parents +0.15.](/kb/shots/find-and-merge-duplicate-people-in-a-gedcom-finder.jpg) 5. Drag **Merge threshold** down to 0.45 to include lower-scoring candidates, or up to 0.75 to narrow them. Tick **show pairs below threshold** to include returned pairs below your threshold. The default floor is 0.30, with exceptions for necronyms and reciprocity findings. The page shows up to 200 pairs, the analysis returns up to 2,000, and candidate generation can skip oversized name groups. The slider does not re-run the search. 6. When you are sure a pair is one person, click **Merge in the workbench**. That opens [Merge Workbench](/merge-workbench) with both xrefs in the URL, so the link is reproducible. 7. In the workbench, check the two pickers, **A (survivor)** and **B (absorbed)**. A keeps its xref, B is removed. Put the record with the better sourcing in A. 8. Walk the comparison table. Each row is one field with four columns: A, B, Choice, Result. The Choice column has three buttons: **A**, **B**, **both**. The default is stated with a confidence and the signals behind it. A row marked `conflict` means the same singleton tag holds different content, and the default for names and events is `both`, so the file shows the disagreement rather than hiding a date. 9. Read **Pointers to B elsewhere** at the bottom. It lists pointers to rewrite to A and duplicate relationship pointers to drop, with line numbers. 10. Click the merge button. It names both records, so merging `@2@` into `@1@` reads **Merge @2@ into @1@**. The whole merge is one ledger patch, and its inverse is written into the file as a `merge-done` determination. 11. Click **Download merged .ged**, then load that download before starting another tool. Page changes do not save edits into the original file. Keep the inverse notes intact and preserve the pre-merge backup; later edits, privacy redaction or other importers can prevent unmerge. 12. When you are not sure, go back to the finder and click **Ask for arbitration** on the pair instead. See the next section. 13. When a pair is two different people, click **Dismiss: not the same person**. That writes a `merge-rejected` determination onto both records. 14. Click **Build GEDCOM with N determinations** and download. Load that file next time and the finder hides every pair you dismissed. ## When you are not sure [Merge Conflict Arbitration](/merge-arbitration) argues one pair both ways. It shows both records in full, the duplicate finder's signal breakdown, the reciprocity flag, the necronym verdict when it fires, and any determination the file already carries for the pair. Two buttons produce a recommendation. **Rule-based answer only** replays the signals and necronym rule in your browser without sending file data. **Ask the model** sends every line of both selected records, linked parents', spouses' and children's names, xrefs and birth/death dates, the score and signals, the necronym flag, and existing determinations for the pair. Read the payload-size disclosure before clicking. Records can include private notes and citations. The request goes through `/api/ai/v1` to OpenRouter and the selected model provider. Model access can open a separate `/ai-access` challenge window. Closing it or encountering a model error returns a rule-based fallback. Check whether the answer says `model` or `rule-based, no model`; a fallback is not an AI assessment. Do not send living people's details without authority to share them. The answer is `merge`, `do-not-merge` or `insufficient-evidence`, with the reasoning, a confidence, and a list of what would settle it. Nothing is applied. The two exits are **Open in merge workbench** and **Dismiss as different people**. ## What to check when it worked - The `INDI` count in [File Inspector](/inspect) drops by exactly one per merge. - Open the downloaded survivor in [GEDCOM Viewer](/gedcom-viewer). Confirm the citations, notes and events you chose to retain. - Open the family the absorbed record belonged to. It lists the survivor once, not twice. - Open [Determination Ledger](/determination-ledger) on the merged file. Every merge appears as a `merge done` row naming both xrefs, and every dismissal as a `merge rejected` row. - Run [Link Reciprocity Checker](/link-reciprocity-checker) on the merged file. A merge that fixed a one-way link makes that finding go away. - Run [GEDCOM Validator](/gedcom-validator) on the download and investigate new errors, including conflicting singleton fields you chose to keep. ## What to do when it did not **The finder shows no pairs and you know there are duplicates.** Lower the threshold to 0.30 and tick **show pairs below threshold**. Missing blocking keys, a low score or result limits can hide a pair. You can select the known xrefs in Merge Workbench or Arbitration for direct review. Add dates or family links only when a source supports them, not to force a match. **A pair you dismissed keeps coming back.** The dismissal only persists in the exported file. Click **Build GEDCOM with N determinations**, download, and use that file from then on. **You merged the wrong pair.** The workbench writes an inverse into the exported file. Recovery needs readable inverse data and compatible current records. See [how to undo a merge you should not have made](/how-to/undo-a-merge-you-should-not-have-made). **A necronym pair is what you want to merge.** The finder omits its merge link at any threshold. Read [how to tell a duplicate from a child named after a dead sibling](/how-to/tell-a-duplicate-from-a-child-named-after-a-dead-sibling) first. Check missing births, death dates, family links and any recorded necronym determination. Correct only source-supported errors. Direct selection in the workbench can still offer a merge, so the finder warning does not replace your review. **The two records disagree about a date and you do not know which is right.** Take `both` in the workbench. The survivor keeps two `BIRT` events, the file records the disagreement, and [GEDCOM Validator](/gedcom-validator) lists it so you can settle it with a source later.