Cleaning Up a GEDCOM Inherited From a Relative

A GEDCOM file handed down from a relative — sometimes after they've passed away, sometimes just found on an old computer or USB drive — is often the entry point into decades of someone else's research. It's also, very often, a file that hasn't been opened or maintained in years, exported from software that may no longer exist, and carrying every data-quality issue that accumulates when nobody's checked a file's internal consistency in a long time. This is a workflow for approaching one of these files methodically instead of guessing where to start.

Step 1: Look at it before you touch it

Before making any changes, open the file in the Viewer and search for a few names you recognize. This does two things at once: it confirms the file actually contains what you think it does (inherited files sometimes turn out to be an unfinished draft, or a different branch of the family than expected), and it gives you a first read on whether names render correctly or look garbled. Garbled accented characters or unexpected symbols in names are the signature of an encoding problem — see GEDCOM Encoding and Garbled Names if that's what you're seeing; it's specifically common in files exported by older software using legacy encodings like ANSEL rather than modern Unicode.

Step 2: Run a full structural check

Older files, especially ones edited by hand or passed through several software migrations over the years, tend to accumulate exactly the issues covered elsewhere in this cluster: broken family links, dangling references, and impossible dates. Rather than checking for each of these separately, run the Validator once — it checks for all of them in a single pass and reports every issue with a line number, which turns "this file has problems somewhere" into a concrete, ordered list you can work through.

Step 3: Decide what's worth fixing versus extracting

Not every inherited file needs a full line-by-line cleanup. If the file is large and you're mainly interested in your own direct line rather than every collateral relative the original researcher tracked, it's often faster to extract just the branch you care about first, then clean up that smaller subset — errors in parts of the tree you're not using don't need your attention. The Tree Splitter can pull out direct ancestors, a specific person's descendants, or people born after a given year, and — unlike a naive manual trim — it rewrites pointers correctly so the extracted file doesn't introduce new dangling references of its own.

Step 4: Get a readable overview before you commit to fixes

Once you've decided what to work with, exporting it to a spreadsheet gives you a plain list of every individual with their resolved name, dates, and parents in one row each — genuinely useful for spotting patterns a line-by-line GEDCOM read would miss, like a surname spelled three different ways across the file, or the duplicate individuals that tend to show up when a relative merged research from multiple sources over the years.

Step 5: Fix the real, sourced problems — don't guess

For every issue the Validator flags, go back to whatever documentation or notes came with the file, if any survived, rather than inventing a plausible-sounding fix. If a birth date is contradictory and there's no way to resolve which value is correct, it's better to record the uncertainty (or remove the value) than to silently pick one guess and present it as fact — a family tree's value depends on the difference between "this is what the record says" and "this is my best guess," and collapsing that distinction is a disservice to whoever inherits the file from you next.

A realistic expectation

A file that's accumulated years of inconsistency won't come out perfectly clean in one pass, and that's fine — the goal of this workflow is to turn an opaque, unfamiliar file into one you understand and trust the shape of, with every known issue documented rather than hidden. That's a meaningfully different (and much more achievable) goal than "zero issues."