What a "Dangling Reference" Error Actually Means (and How to Fix It)

A "dangling reference" is a pointer in a GEDCOM file that leads nowhere — a line that references another record's ID, but no record with that ID actually exists in the file. It's a distinct and more serious problem than a one-way family link, because with a dangling reference, there's genuinely nothing on the other end of the pointer to find.

How GEDCOM pointers work

GEDCOM records refer to each other using an ID surrounded by @ symbols — @I42@ for an individual, @F7@ for a family, @S3@ for a source. A line like 1 FAMC @F7@ means "this person is a child in the family recorded at @F7@." That only works if a 0 @F7@ FAM record actually exists somewhere in the file. When it doesn't — when @F7@ was deleted, never created, or is simply misspelled as @F70@ — the pointer is dangling. (For the full breakdown of how GEDCOM's level/tag/value lines fit together, see the format structure guide.)

The most common causes

Partial exports. If a piece of software exports a subset of a tree — say, just one branch of a family — but doesn't rewrite every pointer to match what's actually included, records that reference something outside the exported subset become dangling. This is exactly the failure mode a well-built export tool needs to avoid; it's why extracting a subset correctly means rewriting pointers, not just filtering records.

Manual deletion. Deleting a person or family record directly in a text editor removes that record, but doesn't automatically find and remove every other line elsewhere in the file that pointed to it. Those pointers are left dangling.

Typos in IDs. A single mistyped character in a pointer — @F17@ instead of @F71@ — produces a reference to an ID that either doesn't exist or, worse, silently resolves to the wrong record if that ID happens to belong to something else.

Software-specific export bugs. Some older or less-maintained genealogy programs have documented issues with source or media pointers surviving in individual records after the source or media item itself was deleted from the program's internal database, producing dangling SOUR or OBJE references even though the individual and family records themselves are fine.

Why this is worse than a one-way link

With a one-way link, both records exist — the relationship is just only recorded from one side, and a reader that starts from the other record will still find it. With a dangling reference, there is no other side. Any tool that tries to resolve @F7@ and comes up empty has to make a decision it wasn't designed to make: skip the field, drop the whole record, or fail. That unpredictability is exactly why import behavior across different platforms is inconsistent for files containing dangling references — there's no single correct fallback, so every program picks its own.

Finding dangling references in your file

Because a dangling reference requires cross-checking every pointer in the file against every record ID that actually exists, manually verifying this in anything but a very small file isn't realistic. The Validator runs this check across the entire file automatically, reports each dangling pointer as an error (since, unlike an implausible date, there's no gray area — the record either exists or it doesn't), and gives you the exact line number so you can find it quickly.

Fixing a dangling reference

Once you've found one, there are two honest fixes: if the record it should point to still exists somewhere (maybe under a different, correctly-spelled ID), correct the pointer to reference the right ID. If the record genuinely doesn't exist anymore — it was deleted on purpose or lost in an earlier export — remove the dangling pointer line itself rather than leaving it in place. Don't fabricate a placeholder record just to make the pointer resolve; an empty record with no real data is worse for anyone using the file later than an honestly missing relationship.