Broken Links in a GEDCOM File: What They Are and How to Repair Them

A family tree is not a list. It is a web. This person is the child of that family. That family is made of these two partners. This birth is backed by that source. In a GEDCOM file, every strand of the web is a link: one record pointing at another by its ID code.

When a link points at an ID that is not in the file, the link is broken. One broken link can orphan a child from a family. A set of them can cut a whole branch off a tree in silence — the people are in the file, but nothing connects them, so charts never show them.

This guide explains how links work, how they break, how to find them all, and how to repair each kind. If you are new to the file form itself, what is a GEDCOM file lays the ground. To find broken links in your own file, the GedConvert tool on the home page checks every link and lists each break with its line number.

How Links Work in a GEDCOM File

Each record has an ID, written between @ signs: @I1@ for a person, @F1@ for a family, @S1@ for a source. A link is just that ID used inside another record. The lines look like this:

See how the links run both ways. The child record says FAMC @F2@: I belong to family F2 as a child. The family record says CHIL @I7@: this child belongs to me. Both lines must exist, and both IDs must be real. That two-way pattern is the heart of the GEDCOM tree, and it is also where breaks do their damage.

Other link kinds follow the same rule. A source citation points at a source record. A note link points at a note record. A media link points at a media record. A family event, a name, a fact — anything that points must point at something that is there.

The Four Kinds of Broken Link

1. The dangling link. A record points at an ID that does not exist in the file at all. FAMC @F99@, and there is no @F99@ family. This is the pure broken link. The target was deleted, left out of the export, or never written.

2. The one-way link. Both records exist, but only one side states the link. The family lists the child; the child never lists the family. Or a person claims a family as a partner, and the family does not list that person. Programs read one-way links in different ways. One builds the tie from the side it finds. Another drops it. The same file yields two different trees.

3. The wrong-kind link. The ID exists, but it is the wrong kind of record. A CHIL line points at a source ID. A source citation points at a person. This often comes from a bad merge or a file that reused IDs across record types.

4. The duplicate ID. Two records share one ID. Every link to that ID now aims at two targets at once. Strictly this is an ID fault, not a link fault, but the harm lands on the links: a child joins the wrong family, a citation backs the wrong event. Validators flag it with the link errors, and it must be fixed before the links can be trusted. The wider fault list is covered in why GEDCOM exports fail validation.

How Links Break

Links rarely break inside a program. A good program guards its own web. Links break at the seams, when data moves.

Partial exports. You export part of a tree — one line, one surname, people born in one place. The program writes the people you picked plus links to families and sources you did not pick. Unless the program trims those links, every one of them dangles. Partial exports are the top cause of broken links in files people share.

Merges. Two files merge, and IDs clash. The merge gives new IDs to some records and misses some links when it rewrites them. Or a person is merged and deleted, while links elsewhere still point at the deleted copy.

Deletes without cleanup. A record is deleted in a program or by a hand edit, but the lines that point to it stay. The delete was clean on one side only.

Hand edits. GEDCOM is plain text, and people edit it. Delete a block of lines in an editor and every point at that block breaks. Change one ID by hand and forget the other side, and you have made a one-way link.

Splits. One tree is split into two files for two branches of a family. The cut runs through families. Both files inherit links to records that now live in the other file.

What a Broken Link Does on Import

Programs answer a broken link in one of three ways, and you rarely get to choose.

Some refuse or warn loudly. They stop the import or present a log of every broken point. That is the honest answer, and the one you want.

Some drop the link and keep the records. The child stays a person in the tree, with no parents. The source citation vanishes, and the event stands with no backing shown. The import "works," and the loss hides until you browse that corner of the tree.

Some guess. A program may attach a one-way link by the side it has, or match a dangling point to a record with a like name. Guesses can join a child to the wrong family. A wrong tie is worse than a missing one, because a missing tie invites a question and a wrong tie looks like a fact.

This is why links get checked before import, not after. Once a program has dropped or guessed, its copy of the tree no longer matches the file, and the file was the only witness to what broke.

How to Find Every Broken Link

You cannot find broken links by browsing a tree. The broken places are, by their nature, the places the tree does not show. You find them by checking the file itself, link by link, against the list of IDs the file holds. That is a machine's job, and it takes seconds on any file size.

A link check reports each break with its line number and its kind: the ID that is missing, the record that points to it, and the link type. It also reports one-way links — pairs where one side exists and the other does not — and duplicate IDs. On GedConvert, that check is part of the validation report on the free plan. You get the list before you decide what to do about it, and before any import has a chance to drop or guess.

Do the count before and after any repair. A clean file reports zero dangling links and zero duplicate IDs. One-way links should be zero too, or each one should be a case you have reviewed and accepted on purpose.

How to Repair Each Kind

The fix depends on why the link broke. There are four honest fixes. Anything else is a guess wearing a repair's clothes.

Repoint the link. The target record exists, but under a different ID. This happens after merges. Find the right record, confirm it by name and facts, and change the link to its ID. Fix both sides if the link is a family tie.

Restore the missing record. The target was left out of an export by mistake. Go back to the source tree, export again with the missing record included, and work from the new file. This is the best fix when the source tree still exists, because it repairs the cause, not the sign.

Remove the link. The target is truly gone — a source you never had, a family that was a false lead, deleted on purpose long ago. Delete the pointing line. The file then states the truth: this record points nowhere because there is nothing to point at. A false link removed is better than a false link kept.

Complete the one-way link. One side states the tie and the records both exist. Add the missing line on the other side: the CHIL line in the family, or the FAMC line in the child. Confirm the tie is a fact first. Completing a link asserts a family tie; assert only ties you believe.

Note what is not on this list: inventing a record to satisfy a link. Do not create a blank person so a child has a family, or a blank source so a citation has a target. A blank record is a false fact that will outlive the repair and mislead the next reader — possibly you, in five years, sure that the blank was real.

Where to Do the Repair: File or Program?

If you still work in the program that made the file, repair there. Fix the tie, delete the stale point, merge the duplicate — then export a fresh file and check it. Program repairs last, because the program is where the next export comes from.

If the file is all you have — sent by a cousin, found in an old backup, exported from a program you no longer own — repair the file itself. That is the case GedConvert's repaired file is built for, with one limit kept firm: the repair fixes format and structure that can be fixed without guessing. A repoint to a clear, sole match and the removal of a point to a record that is not there can be listed and done. A judgment call — which of two people a link meant — stays yours, and the report flags it for you instead of choosing. See the pricing page for how the report and repair plans divide.

After any repair, run the check again on the new file, then import into a new, empty tree and compare counts: people, families, and sources in the report against the tree. If the counts match and the link report is clean, the web is whole.

Habits That Keep Links Whole

Export whole trees when you can, and treat partial exports as drafts, not as files to build on. If you must share one branch, say so, and let the receiver know the file's links to the rest of the tree were cut on purpose. After any merge, run a link check before you do new work on the merged tree. Keep the file that passed the check as your master copy, beside the program's own store. And when you back up, back up the checked file — the routine in how to back up your family tree builds the check into the habit.

Frequently Asked Questions

How do I know if my file has broken links without special software? A rough hand check exists: list every ID that records define, then search the file for each ID used in a link. On any file past a few hundred lines, this stops being practical. A validator does the same check fully in seconds, which is why the check is part of the free report.

A child shows in my program with no parents. Is that a broken link? It may be. The child may have lost the FAMC link, or the family record may be missing from the file. Or the child truly has no known parents recorded. Check the file: if the child has a FAMC line, follow its ID. No line means no tie was ever written.

Can a broken link join someone to the wrong family? A dangling link cannot — it points at nothing. A duplicate ID can, and a program that guesses can. That is why duplicate IDs are fixed first and why imports that guess are a risk.

My file has hundreds of broken links after a partial export. Is it ruined? No. The people and facts are still there. The links to records outside the export dangle by design. If the partial file is for sharing one branch, remove the dangling points or leave them with a note to the receiver. If it is your main file, re-export the whole tree.

Should sources with broken links worry me as much as family links? Yes, for a different reason. A broken family link changes the tree shape. A broken source link strips the backing from a fact, and the fact still shows as if it were backed. Both belong on the repair list.

Will a one-way link show as an error everywhere? No, and that is the trap. Some programs complete one-way links silently, some drop them silently. The file is the only place the truth can be checked, which is why the check runs on the file.

References

• https://gedcom.io/ — The home of the GEDCOM standard, whose specs define record IDs and the cross-reference links between records.
• https://www.archives.gov/research/genealogy — The U.S. National Archives guide to genealogy research and records.
• https://www.loc.gov/ — The Library of Congress, a major source of census, local history, and family history material.