How to Validate a GEDCOM File Before Importing It Anywhere

Whether you're importing a GEDCOM file into FamilySearch, a desktop program, or merging it into an existing tree, running a validation pass first turns "upload it and see what happens" into a predictable process. This is a general-purpose checklist — it applies no matter where the file is headed, not just to any one platform.

Why validate before import, not after

Every import destination handles a structurally flawed file differently: some reject it outright with a generic error, some silently skip the records that don't resolve cleanly, and some import everything but leave your tree quietly inconsistent. None of those outcomes are as easy to work with as fixing the file yourself first, where you can see exactly what's wrong and exactly which record it's in. If you've already run into cryptic failures on a specific platform, Common GEDCOM Upload Error Messages, Explained maps several frequent error strings back to their actual structural cause.

Step 1: Confirm the file opens and parses cleanly

Before checking anything else, confirm the file itself is readable — no corrupted header, no encoding that turns names into garbled symbols. Opening it in the Viewer is the fastest way to confirm this: if you can search for a person and see a sensible pedigree, the file's basic structure and encoding are sound.

Step 2: Run a full structural validation

This is the core of the checklist. The Validator checks the whole file in one pass for the three categories of structural problem that most commonly break an import: dangling references (pointers to records that don't exist — see What a "Dangling Reference" Error Actually Means), one-way family links (see How to Fix Broken Family Links), and contradictory or implausible dates (see Finding and Fixing Impossible Dates). Each issue is reported with a line number, so you can go straight to the source rather than searching the file manually.

Step 3: Fix errors first, then review warnings

The Validator separates issues into errors (always wrong — a death before a birth, a pointer to a nonexistent record) and warnings (worth a look, but not necessarily wrong — an implausible-but-not-impossible lifespan, for instance). Clear every error before importing; they're the issues most likely to cause an import to fail or silently drop data. Warnings are worth reviewing but can be a judgment call — some will turn out to be genuine, well-documented outliers.

Step 4: If you're headed to FamilySearch specifically, check size and count too

Structural validity and practical importability are two different questions. A perfectly well-formed file can still be too large or contain too many individuals for a specific platform's practical limits — this is a separate, platform-specific check, not something a general structural validator can tell you. If FamilySearch is your destination, run the file through the Upload Readiness Checker as well, which checks it against documented FamilySearch failure patterns around file size and individual count, and hands off directly into the Tree Splitter if the file needs to be broken into a smaller piece first.

Step 5: Re-check after any fix

Every time you edit the file — whether by hand or through another program — treat it as a new file for validation purposes. A single edit made to fix one issue can occasionally introduce another (adding a CHIL line to resolve a one-way link, for instance, if mistyped, could create a new dangling reference). Running the Validator again after edits costs a few seconds and confirms the fix actually worked rather than just assuming it did.

The short version

Open it, run the Validator, fix every error, review the warnings, and if you're headed to a platform with known practical limits, check those too. Five minutes spent this way before an import is almost always faster than discovering the same problems through a failed or partially-completed upload.