How to merge two family-tree files without damaging either of them. Everything here happens on your own computer.
You have two GEDCOM files with some of the same people in them. Perhaps a cousin sent you their research, or you exported the same tree from two programs years apart. Merging them is the moment where years of work can quietly go wrong: two records for the same great-grandmother, a birth year silently overwritten, a source citation dropped without a word.
GedMend sits before that merge. It reads both files, finds the people and families that look like duplicates, shows you each disagreement side by side, and writes a new merged file containing only what you confirmed.
What GedMend is not:
This is the part worth being sure of before you start, so here it is plainly.
Your original files will not be changed. GedMend opens both of them for reading and never writes to either one. When you export, it writes a new file at a path you choose. Whatever happens in between — however many decisions you make or undo — File A and File B are exactly as you loaded them.
Nothing is written until you press Confirm & Export. The first five steps produce nothing on disk except your own saved decisions, which are a few kilobytes and contain no genealogy data. You can walk the whole wizard, change your mind, and close the program, and no file has been created.
Your genealogy data never leaves your machine. There is no account, no upload, no sync and no "anonymous usage statistics". GedMend contains no network code of ours, which is why it works identically with your internet disconnected. The one exception is not about your data at all: if you choose to buy the export unlock, that button hands the request to your platform's app store — the Microsoft Store on Windows — and the store talks to its operator. Your files are not involved.
Everything except writing the merged file is free, permanently, on your own files: loading, the summaries, finding duplicate people and families, every conflict shown side by side, the change report, the final check. There is no trial period and no countdown.
Only export — actually writing the merged GEDCOM — is a one-time purchase. It unlocks on the machine you bought it on and stays unlocked; there is nothing to copy, email or paste, and no key to lose.
Until then the header shows Export locked, and a notice explains that export is the paid step. The badge names the one thing that is withheld, which is also a fair summary of everything else: nothing is on a countdown, and nothing you can already do stops working. Once you buy, the badge disappears altogether rather than changing to say something else. Nothing about the output is degraded when you do unlock it: there is no watermark, no reduced file, no sample-only mode. The purchase unlocks the action, and does not touch the result.
If you press Confirm & Export before buying, everything you did upstream is still there. The purchase panel opens, and if you complete the purchase the export continues in the same sitting — no restart, no reloading your files. If you close the panel instead, nothing is lost and nothing is broken; you are simply back where you were.
GedMend asks for two files, and the order matters.
If you get them the wrong way round, nothing is damaged — but you will find yourself choosing "Keep B" on nearly every disagreement, which is the signal to go back and swap them.
If you have used GedMend before, the opening screen also lists your recent sessions so you can pick up where you stopped. See §13.
Two cards, one per file: how many people and families are in it, what character encoding it uses, which version of the GEDCOM standard it follows, and anything odd noticed while reading it — records pointing at people who are not in the file, people with no name, empty families.
Read the counts. If a file has far fewer people than you expected, you have probably picked the wrong file, and it is much cheaper to notice that here than three steps later.
A GEDCOM file is text, and text files have to record how letters are stored. That choice is called the encoding. Genealogy files use several, for historical reasons:
GedMend detects the encoding, decodes both files correctly, and writes the merged file in UTF-8. When the two files use different encodings it says so on this screen. That is a notice, not a failure — mixed pairs are normal and handled.
One more case: a file can claim one encoding in its header and actually contain another. Inherited files do this routinely. GedMend does not crash on those, and it does not simply believe the label either — it decodes what is really there, and tells you when the two disagreed.
GedMend reads GEDCOM 5.5, 5.5.1 and 7.0. It writes 5.5.1, and can write a compatibility 7.0 export if you ask for one at the final step.
If your two files use different versions, that is fine and common; both are read correctly. You will see a note if you load a 7.0 file and then export as 5.5.1, because 7.0 can express a few things the older version cannot. Nothing is silently discarded — the change report records what happened.
This is where the work is. GedMend has compared everybody in File A with everybody in File B and produced a list of candidate pairs: two records that might be the same person. Your job is to go down the list and say which ones really are.
A candidate is a suggestion, never a decision. Until you say so, nothing is merged.
Each pair carries a score out of 100. It measures how much the two records look alike — nothing more. It is not a probability, and it is not GedMend's opinion about whether they are the same person. It cannot be: two different men genuinely named John Smith, both born in Leeds in 1834, will score very high, and they are still two men.
The score adds up six comparisons, weighted by how much each one tends to be worth:
| What is compared | Share of the score |
|---|---|
| Names — given and surname, allowing for spelling and sound | 35% |
| Birth date | 20% |
| Family connections — the same spouse, parents or children | 20% |
| Death date | 12% |
| Places | 8% |
| Sex | 5% |
Names are compared generously on purpose: "Jno." matches "John", "Wm" matches "William", nicknames are expanded, capital letters and accents are ignored, and names that sound alike score partially even when spelled differently. Dates are compared with tolerance, so "about 1832" and "1833" are close rather than simply unequal.
Every card can show its own arithmetic — open why it matched and you get the six parts and what each contributed. If a score surprises you, read the breakdown before trusting or dismissing it. The same comparison always produces the same number: there is no learning, no randomness and no artificial intelligence involved, so the list you see today is the list you will see tomorrow.
The slider sets the lowest score you want to see. It starts at 70. Drag it down and more, weaker candidates appear; drag it up and the list shortens to the strongest.
The slider changes the view and nothing else. It never makes, changes or erases a decision. A pair you marked as the same stays marked when you raise the threshold past its score — it just stops being listed until you lower the slider again, and the decisions list still shows it.
A practical way to use it: start at the default and work down the strong matches, which are mostly obvious. Then lower the slider in stages. The interesting cases — the same person recorded with a nickname and a wrong decade — usually live between 40 and 70.
Every candidate gets one of three answers, by button or by key:
Undecided is a real answer, not a postponement you will be nagged about. An undecided pair is treated as two different people: both records survive into the merged file. Nothing is lost by leaving something undecided — which is the safe direction, because two records for one person can be merged later, while one record wrongly built from two people is very hard to take apart.
One Same per person. A person in File A can be confirmed the same as only one person in File B, and the reverse. If you mark a second pair involving someone already matched, GedMend tells you, and the earlier decision gives way to the new one. You can undo it.
On a real tree this list is long. Two tools stop it being a scroll.
Find (Ctrl+F) jumps to a person by name, year or record
number. It moves you to the match rather than filtering the list, so you keep your place
in the sequence. Type a name; you can also use * to stand for any ending
(Sm* finds Smith and Smythe) and ? for exactly one letter
(Sm?th finds Smith and Smyth). Capital letters and accents are ignored. The same
rules are shown next to every box you can type a query into.
Review decisions (Ctrl+D) lists everything you have decided so far, with the names on both sides. Click a row and it takes you back to that pair. It is read-only: looking at the list can never change a decision. Rows can be sorted and filtered, which is the fastest way to answer "did I already deal with the Hendersons?"
The Match step has two tabs. The second, Families, finds duplicate families — the same marriage recorded twice, with the same children attached twice.
It is empty at first, and that is correct. A family is defined by the people in it, so GedMend cannot suggest that two families are the same until you have confirmed that at least one shared spouse is the same person. Work through Individuals first; family candidates appear as you go.
Family candidates work exactly like people: a score, a breakdown you can open, and S / N / U. Each card shows the spouses and children on both sides, which is usually enough to decide at a glance. This tab surfaces the families that look like duplicates; it does not claim to find every one.
Remarriages stay separate. A man married twice has two families, and GedMend is built not to collapse them into one. If you see two families sharing one spouse but with different partners, that is a remarriage and the answer is Not the same.
Changing your mind cascades. If you go back and change a spouse decision that a family candidate depended on, that family returns to Undecided rather than standing on a decision you have withdrawn. You will need to look at it again — the alternative is a family merge quietly resting on something you no longer believe.
When two families are confirmed the same, they are combined: everything from both is carried into one family. There is no field-by-field choosing for families in this version.
Now that you have said who is the same person, the two records for each of those people may disagree. This step shows every disagreement, one confirmed pair at a time, in two columns: File A on the left, File B on the right.
Each disagreeing field offers four answers:
Whichever you pick, the citations from both records are kept — the value is the choice, the evidence is not. 12.4 covers exactly where the evidence for the value you did not keep ends up, and when Both is the better answer.
Every row starts on Keep A, marked as a default until you choose. That marking matters: it is the difference between "GedMend picked this" and "you picked this", and the change report records which of the two it was.
The reason for the default is that File A is your master. If you resolved nothing at all, the merged file would keep your existing tree's values throughout — the outcome least likely to surprise you. It is a starting position, not a recommendation. Where you know File B is right, change it.
A field is only a disagreement if both files have a value and the values differ. If a field exists in only one of the two files there is nothing to choose: it is carried into the merged record automatically. A death place recorded only in your cousin's file is simply kept.
This holds at every level of detail, not just for whole fields — a note attached to a birth, a citation attached to an event, a detail hanging off a name. Choosing a value for one field never discards anything else attached to the record.
Ctrl+Z undoes your last decision; Ctrl+Y (or Ctrl+Shift+Z) puts it back. This works across the whole session and covers match decisions, family decisions and field choices alike.
Undo is completely safe here, because nothing has been written yet. There is no file to roll back — you are only changing your mind about what the export will contain.
Before anything is written, GedMend shows what the merged file will contain and checks its own arithmetic.
The equation on this screen is simply:
people in A + people in B − pairs you confirmed as the same = people in the merged file
Every pair you confirmed removes exactly one duplicate, so the total must come out exactly. The same check runs separately for families. If the numbers agree, the merge did what you told it to. If they do not, GedMend says so rather than writing the file quietly — that is a fault worth reporting, not something to work around.
This warning lists pairs that scored high — at or above 70, the same bar the slider starts at — which you did not confirm as the same person. Both records will be in the merged file.
This is not an error, and it is often the right outcome. It appears when you deliberately answered Not the same, and equally when you never reached the pair at all because it sat below the threshold you were working at. GedMend cannot tell the difference between a careful decision and an oversight, so it names the pairs and leaves the judgement to you.
What to do: read the list. If every pair on it is one you consciously separated, you are finished. If a name on it makes you pause, go back to the Match step, find that pair, and look again.
Choose where the merged file goes. Pick a new name — tree-merged-2026.ged rather than
the name of either original. GedMend will not write over an input file, but a clearly new name
also saves you from confusing yourself in six months.
Then choose the version:
Confirm & Export writes the merged file, and beside it a change report. The confirmation screen shows where both went and reminds you that your originals are untouched.
Sensible next step: open the merged file in your genealogy program as a new tree, not by importing over your existing one. Look at a handful of the people you merged. Only when you are satisfied should the merged file become your working tree.
Every export also writes a change report, in two forms: a web page you can open in a browser, and a plain-text version that will still be readable in twenty years. They contain the same account of what happened.
The report lists:
Keep it with the merged file. It is the only record of what you decided. In a year, when you wonder why your grandmother's birth year is 1834 and not 1836, the report is the answer — and it names the decision as yours or as the default, which is exactly the distinction you will want.
Citations are the reason to be careful with a merge, and the thing most likely to be lost by one. An unsourced tree is a rumour.
Every source citation is preserved. When two records for one person are combined, the merged record carries the citations from both. Choosing "Keep A" for a birth year does not discard File B's evidence for its birth year — the value is a choice, the citations are kept regardless.
If both files carry the identical citation, it appears once rather than twice. Citations that differ in any way are all kept, because "nearly the same" is not the same, and deciding otherwise would be GedMend throwing away evidence on your behalf.
A citation does not have to hang off the person. In a GEDCOM file it can be attached to three different things, and programs differ in which they use:
All three are kept, and each stays where it was. A citation attached to a birth arrives still attached to that birth, not loosened into a general note about the person. That matters because a citation that floats free of the event it supports has lost most of its value.
This is the one that surprises people, so it is worth stating plainly. If File A cites Parish Register, folio 3 and File B cites Parish Register, folio 4, the merged record keeps both. They are not a duplicate. They are two different pages of the same book, and each supports something.
Only citations that are identical in every part are folded into one. Anything less than identical is treated as separate evidence and kept. So if the merged file looks like it has "the same source twice", read the detail — the page, the date, the note attached to it — and you will usually find it does not.
Most files keep a list of sources — the registers, censuses and certificates themselves — with the citations pointing into it. When two files are merged, both lists arrive, along with any repository details: which archive holds the original, and its call number or shelf mark. Nothing in that chain is dropped.
One consequence is worth expecting. If both of your files independently describe the same parish register, you will see it twice in the merged source list. GedMend does not merge source records, because it cannot safely tell that two descriptions of a register are the same physical thing — and quietly collapsing them would repoint every citation that relied on them. Merging duplicate sources is a tidying job your main genealogy program is better placed to do, once you can see them side by side.
This is the case worth knowing before you reach step 4. Your file says the birth was 1834, citing folio 3 of the parish register; the incoming file says 1836, citing folio 9 of the same register. You keep 1834.
GedMend writes one birth, reading 1834, carrying both folios. Folio 9 is not discarded along with the year it supported, it is not loosened up onto the person, and it is not altered to look like support for 1834. The limit is the format's: GEDCOM attaches a source to an event, not to a date inside one, so folio 9 stays on a birth whose date now reads 1834, and the file itself no longer records that folio 9 was the reason anyone wrote 1836. The change report does — it lists the value you chose for every conflict.
If you need that distinction kept in the file rather than in the report, choose Both at step 4. GEDCOM permits two birth structures on one person, and that is what GedMend then writes: 1834 with folio 3, 1836 with folio 9, each year carrying its own evidence on its own event.
You do not have to take any of this on trust. The change report gives you the numbers for every person that was merged:
Citations: A=2 B=3 merged=4
Two from File A, three from File B, four in the result — meaning one citation was present in both files and folded into a single entry. Add the two input numbers, subtract the number that folded, and you have the total that should be there. If a merged count is ever lower than the larger of the two inputs, something is wrong and we would want to hear about it.
A large reconciliation takes more than one sitting, so GedMend saves as you go.
There is no Save button, and that is deliberate. Every decision is written down the moment you make it, along with your undo history. If the machine loses power mid-session you lose nothing you had decided.
Only decisions are saved — never your genealogy data. A saved session is a few kilobytes: which pairs you judged the same, which field values you chose. Your files are not copied anywhere.
When you reopen GedMend, saved sessions are listed newest first with both file names, the date and how many matches you confirmed. Choose one and it re-reads your two files, re-applies everything you decided, and returns you to the step you were on.
Resume checks your files first. Before restoring anything, GedMend confirms both original files are still where they were and still identical to when you saved. If either has been moved, renamed, edited or re-exported, it refuses to resume and offers to start fresh instead. It is refusing on purpose: your decisions refer to records in specific files, and applying them to a changed file would attach your judgements to the wrong people.
Switching sessions — the header menu has Switch Session, which takes you back to the session list without closing the program. Your current work is saved before you leave, and appears in the list to return to.
The whole program can be driven from the keyboard. On the Match step in particular it is much faster than the mouse: your hand stays on S, N, U and the arrow keys, and hundreds of pairs go by without reaching for anything.
The per-step tables appear here when this guide is opened inside GedMend — they are read from the program itself, so they always match the keys it actually responds to.
| What it does | Keys |
|---|---|
| Open this guide | F1 |
| Open the header menu | Ctrl+M |
| Undo the last decision | Ctrl+Z |
| Redo it | Ctrl+Y / Ctrl+Shift+Z |
| Close a panel or dialog | Esc |
Every message GedMend can show you, what it means, and what to do. If you are here because something appeared on screen, find it in the left column.
| What you saw | What it means, and what to do |
|---|---|
| The two files use different encodings | Normal and handled — both are decoded correctly. Check a few accented names read properly, as described in §5.1, then carry on. |
| The encoding could not be determined | The file gave no usable clue about itself, so Windows-1252 was assumed. Usually right for Western-European files. Check accented names with extra care; if they are wrong, re-export the file from your genealogy program choosing UTF-8. |
| Exporting a 7.0 file as 5.5.1 | One of your files uses the newer standard and you have chosen the older one for output. A few newer constructions cannot be expressed in 5.5.1. Nothing is dropped silently — the change report records it. Choose 7.0 at export if your program accepts it. |
| This session can't be resumed — a file has changed | One of the two originals is no longer identical to when you saved. Your saved decisions point at records in the file as it was, so applying them now could attach your judgements to the wrong people. Either restore the original file, or choose Start fresh. Your saved work is not deleted by this refusal. |
| This session can't be resumed — a file is missing | A file has been moved, renamed or deleted. Put it back where it was, or start fresh. |
| Some duplicates may have survived | High-scoring pairs you did not confirm are both in the output. Often correct — see §9.2. Read the list and satisfy yourself each one was intentional. |
| Conflicting decision — two pairs claim the same person | Someone has been confirmed the same as two different people. Only one can be right. Open Review decisions (Ctrl+D), find the person, and settle it before continuing. |
| Export is the one paid step | You reached the final step in trial mode. Everything you decided is intact. Complete the purchase and the export continues in this same sitting — see §3. |
| The Store is not available right now | The purchase could not be reached — usually no internet connection, occasionally Store maintenance. Nothing is charged and nothing is lost; GedMend stays in trial and you can try again. All your analysis is unaffected, since it never needed a connection. |
| This file is too large to load | The file is beyond what GedMend will attempt, so it declines rather than exhausting memory part-way through. Splitting a tree this size before merging is the practical route. |
| Problem in the file at line N | Something at that line does not follow the GEDCOM format. The line number is exact — open the file in a plain text editor and look. Most often it is a stray blank line or a truncated export. Re-exporting from your genealogy program usually fixes it. |
I45, F12,
S3. Meaningful only inside its own file; the same person will have different
numbers in your two files. GedMend renumbers where it must, so nothing collides.
This guide documents GedMend v1.0.3.
If your program can export a GEDCOM file and import one, yes — which covers RootsMagic, Legacy, Family Tree Maker, Gramps, Ancestral Quest, Heredis and the exports from Ancestry, MyHeritage and FamilySearch. GedMend reads GEDCOM 5.5, 5.5.1 and 7.0, and writes 5.5.1 by default because everything in common use reads it. It does not connect to any of those services or read their files directly; you export, GedMend works on the exported files, and you import the result.
No. GedMend opens both files for reading only and writes a new merged file at a path you choose. Your originals are exactly as you loaded them when it finishes. See §2.
Merge two, then merge that result with the third, and so on. GedMend works on two files at a time on purpose: reconciling three at once means resolving disagreements between three versions of the same person, which is far harder to get right and far harder to check afterwards.
Not for any of the work. Loading, matching, resolving, previewing and exporting all run offline — GedMend contains no network code of ours, so your genealogy data never leaves your machine. The one step that needs a connection is the purchase itself, which your operating system handles in its own app store (the Microsoft Store on Windows).
One thing: the ability to write the merged file. Everything else — loading your files, finding duplicate people and families, every conflict side by side, the change report, the final count check — is free, permanently, with no time limit.
It is a one-time purchase of $29.99, not a subscription. It never expires, it covers every 1.x update, and there is no watermark or degraded output at any point. Microsoft handles the payment and is the merchant of record, so the price you actually see is the one for your country including any local tax.
It is tied to the Microsoft account you bought it with, the same as any Store purchase, so it follows you to a new PC when you sign in there. There is no licence key to copy, email or lose.
Refunds go through the app store you bought from, under that store's refund policy — on Windows, the Microsoft Store, with Microsoft as merchant of record. We are not in the middle of that transaction and cannot be. Worth saying plainly, though: you can run the entire analysis on your own files before paying anything. If GedMend is not going to help with your particular files, you will know before you reach the purchase.
No. Updates within version 1 are free and arrive automatically through the app store you installed from — on Windows, the Microsoft Store. Any fix that prevents lost data or a dropped citation ships free and immediately, to everyone.
Windows, for now — sold, installed and updated through the Microsoft Store, and nowhere else. A Mac version is possible one day; it is not a promise, and nothing here should be read as one.
Nowhere. There is no account, no upload, no sync, no telemetry and nothing to opt out of. The full statement is on the privacy page, but the short version is structural rather than a policy you have to trust: the program has no network code of ours in it, so there is nothing to send your files anywhere even if we wanted to.
[email protected]. If it concerns a specific merge, the change report saved beside your merged file is the most useful thing you can describe — please do not send us your genealogy files, and we will never ask for them.