Check a GEDCOM file before you import it

The short answer

Preserve the original GEDCOM and import a copy into a separate test tree. Check privacy, people, relationships, sources and media references before merging anything into your master tree.

A GEDCOM can be structurally valid and still be a bad import for your archive. It may contain living people, duplicate identities, inconsistent places, unsupported custom fields or references to media files that never arrived.

The safest check combines file-level facts with a human review of the imported result.

Open the free GEDCOM import review record (.txt). Save a copy beside your test file and record the expected result, observed result and next action. No account, email address or GEDCOM upload is required to use the template.

Preserve the original first

Do not edit or repeatedly overwrite the received file. Make a working copy and record:

• the original filename and date received;
• who or which program supplied it;
• the export date, if known;
• the source program and version;
• the GEDCOM version and character encoding shown in the header;
• whether the export covers the whole tree or one branch;
• a SHA-256 checksum or another integrity record.

A normal GEDCOM uses the `.ged` extension and structured text records. The file begins with a header and ends with a trailer. Those facts help identify obvious truncation, but they do not prove that the genealogy is correct.

→ Understand how a GEDCOM file works

Review privacy before any online upload

Assume the file may contain more than visible names and dates. Review it for:

• living people and their relationships;
• birth dates, addresses and contact details;
• private notes or sensitive family circumstances;
• submitter or researcher contact information;
• source transcriptions that reveal protected details;
• confidential information copied into custom fields.

Create a purpose-specific export when possible. A private preservation copy can retain information that should not appear in a file shared with a relative or uploaded to a public service.

Do not use an unfamiliar online checker merely to inspect the file. Confirm where processing happens and what the service stores.

Clean the source tree when you control it

FamilySearch recommends correcting common problems before export or upload: standardizing names, dates and places; finding duplicate people and places; checking unattached people; and reviewing notes and privacy.

→ Review GEDCOM privacy before sharing a copy

If you control the source program, fix clear structural problems there and create a new export. That preserves a clean source of truth. Avoid using raw text edits as the normal way to repair genealogy data.

If the file came from someone else, record the issue rather than silently changing their original.

Inspect the import in a separate test tree

Never make the first import into the only master tree. Create a clearly named test database such as:

`TEST_Carter-GEDCOM_received-2026-08-30`

Import the working copy and keep the test tree isolated. Do not enable automatic merging or online sync during the first review.

Capture the import summary and any warnings. A program may skip unsupported structures without making the loss obvious later.

Check identities and relationships

Compare the source expectations with the imported tree:

1. total people and family counts;
2. the starting person and immediate family;
3. parent-child links across several generations;
4. spouses, partners, adoptions and step-relationships;
5. unattached people;
6. duplicate individuals with similar names and dates;
7. living-person status and privacy flags.

Do not merge two people because the name and birth year match. Use sources, places, relatives and event context to support identity.

Check dates, places and characters

Sample exact, approximate, ranged and uncertain dates. Confirm that the receiving software has not converted uncertainty into false precision.

Review places with multiple jurisdiction levels and historical names. Similar places written in different forms can produce duplicate place records, while aggressive standardization can erase useful historical context.

Check names and notes containing accents, apostrophes, non-Latin scripts and line breaks. Garbled characters often point to an encoding or software-support problem.

Check sources, notes and custom data

Select several people with strong documentation and compare:

• source titles and repository details;
• citation text and page numbers;
• links between citations and events;
• research notes and transcription formatting;
• shared notes or sources;
• custom facts, tags and witness roles;
• any unsupported-field warnings.

Different programs model sources and custom data differently. A clean people count cannot confirm that evidentiary context survived.

Check media separately

GEDCOM usually does not contain the image, audio or document bitmap itself. It may carry a path or reference that only works on the original computer.

For a meaningful test:

• obtain the related media folder when permitted;
• compare its file inventory with media references in the imported tree;
• open several originals, not only thumbnails;
• check whether folder paths changed;
• preserve rights, provenance and source identifiers.

Missing media is not repaired by importing the GEDCOM again.

Worked example: matching counts, missing evidence

These numbers describe a fictional teaching example, not a software benchmark or a customer result. The source tree has 120 people. Its export note identifies eight media files and twelve source citations to inspect. A test import reports 120 people and no fatal error.

That is a useful first check, but it is not a pass. Compare the sample against the source:

• People: 120 expected, 120 imported. The count agrees; inspect relationships and duplicate identities separately.
• Media: eight expected files, five that actually open from the test tree. Record which three fail and whether they are absent or their paths have changed.
• Citations: twelve selected citations expected, eleven still attached to the intended facts. Record the missing link, even if the source title survived elsewhere.
• Dates: a sampled approximate birth date still says “about 1871,” rather than an exact date. Record this as a sample pass, not proof that every date transferred correctly.

Decision: hold the merge. Obtain or relink the missing media in the test copy, investigate the detached citation, then repeat those checks. Preserve the original export and import log. The source software may need a corrected export; a second import into the master tree is not a repair strategy.

Your review record should distinguish pass, issue and not checked. A blank cell must never silently become a pass. For a large tree, write down the sample you actually inspected and keep the unsampled records explicit.

Decide whether to merge, rebuild or stop

After the test, create a short reconciliation note listing:

• what transferred correctly;
• what changed or disappeared;
• duplicate risks;
• privacy changes required;
• media still missing;
• the intended merge or rebuild method;
• the backup made before any master-tree change.

If the import creates many uncertain duplicates or strips important source structure, a selective manual transfer may be safer than a bulk merge.

FamilySearch warns that bulk copying can create duplicates or overwrite better information. Its upload experience is also changing, so follow the current instructions shown for your account rather than an old tutorial.

→ Back up an Ancestry tree before moving data

→ Move a Family Tree Maker archive to a new computer

A final pre-import checklist

Before the GEDCOM touches the master tree, confirm:

• the original file remains unchanged;
• the source program, version and export scope are recorded;
• privacy has been reviewed;
• the test import completed without unexplained warnings;
• identities and relationships passed a sample check;
• dates, places and characters remain intelligible;
• sources, notes and custom fields were sampled;
• media is accounted for separately;
• the master tree has a fresh restorable backup;
• the merge plan and rollback point are written down.

If any answer is unknown, pause at the test tree. Uncertainty is much cheaper before a merge.

Official references

• FamilySearch: prepare a GEDCOM before copying information into Family Tree
• FamilySearch: the new GEDCOM upload experience
• FamilySearch GEDCOM 7 specification
• FamilySearch GEDCOM specifications and tools

Wiserta is independent and is not affiliated with or endorsed by FamilySearch, Ancestry, Software MacKiev or Family Tree Maker. Product and company names belong to their respective owners.