Why GEDCOM Exports Fail Validation — and How to Fix Them

You export your tree. The file looks fine. Then a validator, a new program, or the GedConvert tool on the home page reads it and hands you a list of errors. Some files get a short list. Some get hundreds of lines. Your first thought is that the export is broken. Your second thought is worse: is my tree broken?

In most cases, your tree is fine and the file has faults. There is a real gap between the two. The tree lives inside your program, where the program guards it with its own rules. The file must follow the GEDCOM spec on its own, line by line, with no program to help it. Small slips that the program never showed you become errors the moment the file stands alone.

This guide names the faults that cause most validation failures, tells you which ones matter, and shows how each one is fixed. Two faults get their own full guides: broken links in a GEDCOM file and GEDCOM dates explained. Read this one first for the full map.

What Validation Actually Checks

Validation means reading the file against the spec. The spec is a book of rules: what lines may appear, in what order, with what values, and how records point to each other. A validator checks each rule it knows and reports each break it finds, with a line number.

A good report sorts problems by weight:

Counts alone do not tell the story. One error in the header can matter more than fifty warnings about style. Read the first errors first. They often cause the later ones, and fixing the top of the list can clear half the report in one move.

Fault 1: A Bad or Incomplete Header

Every file starts with a HEAD record. It must hold the source program, the GEDCOM version, and the character encoding. Exports go wrong here in plain ways. The version line is missing. The encoding line names a form the file does not use. The header points to a form feed or a submission record that is not in the file.

Imports lean on the header hard. A program reads it first and sets its rules by it. A wrong version line makes the program apply the wrong rule book to all the lines that follow. A wrong encoding line garbles every special letter in the file. Fix the header and a long error list can shrink at once.

Programmes that export by hand, or old tools that no one maintains, are the usual source. The fix is a format repair: rebuild the header to match the real content of the file. That is a safe fix, because the header describes the file; it holds none of your family facts.

Fault 2: The Wrong Encoding

The file states one encoding and uses another. The classic case: the CHAR line says ANSEL, but the file was saved as UTF-8, or the reverse. Names with accents, umlauts, or letters from other alphabets break first. Some validators flag each bad byte. Others flag the file once and refuse the rest.

Encoding faults deserve their own full guide, and they have one: GEDCOM encoding errors explained. The short fix: read the file with the map that matches its real bytes, then save it as UTF-8 with a CHAR line that says UTF-8. GEDCOM 7.0 files must be UTF-8, so this fix also readies a file for conversion.

Fault 3: Broken Links Between Records

A GEDCOM file is a web of points. A family record points to its partners and children. A child points back to the family. An event points to a source. When a point aims at an ID that is not in the file, the link is broken. When a family lists a child but the child does not list the family, the link is one-way, and programs treat it in different ways.

How do links break? A merge gone wrong is one cause. A partial export is another: the program exported the people but left out some families or sources. A hand edit that deleted a record but not its points is a third.

A broken link is an error, not a warning, because the tree shape depends on it. The fix depends on the cause. If the target record exists under a new ID, repoint the link. If the target is truly gone, remove the point so the file states the truth. The full method is in how to fix broken links in a GEDCOM file.

Fault 4: Duplicate and Reused IDs

Each record ID must be used once. Some exports reuse an ID after a merge or a split. Two people end up as @I42@. Now every point to @I42@ is a guess. Programs resolve the clash in their own way: one keeps the first person, one keeps the last, one stops the import.

A close cousin of this fault is the same person entered twice under two IDs. That is not a format error — the file is legal — but validators often flag it as a warning when name and dates match closely. The format fault can be fixed by a tool: give each record its own ID and repoint the links. The research fault, two records for one real person, is yours to judge. No tool should merge people on its own.

Fault 5: Dates That Break the Grammar

GEDCOM dates follow a strict grammar. A full date is day, month code, and year: 12 MAR 1904. The spec allows ranges and loose forms, such as BEF 1900, BET 1880 AND 1890, and ABT 1850. What it does not allow is free text in the date field itself, such as "March 12, 1904?" or "sometime in spring."

Exports fail here when a program lets users type dates as free text and then writes that text into the DATE line as-is. Each bad date is one error, so a tree with loose date habits can earn hundreds of errors from this one fault. There is also a class of warnings no grammar can catch: dates that are legal but cannot be true, like a birth after a death, or a child born to a parent aged six. A good validator flags both kinds. The grammar, the calendars, and the checks are covered in GEDCOM dates explained.

The fix for grammar faults is to move the loose text into a note and put a legal form in the date field. "Spring 1904" becomes ABT 1904 with the words kept in a note. The fact stays. The form becomes valid.

Fault 6: Lines That Are Too Long or Split Wrong

GEDCOM began in a time of short lines. In 5.5.1, a line holds at most 255 characters. Long values, such as a long note or a long place name, must be split across lines with CONT and CONC tags. CONT adds a new line of text. CONC adds text to the same line.

Exports break this in two ways. Some write one very long line and let the reader cope. Others split a value in the middle of a word with the wrong tag, so the value gains a space or a line break it should not have. Names and notes come back subtly wrong after import.

GEDCOM 7.0 removed the length limit, so this fault fades as 7.0 spreads. For 5.5.1 files, the fix is a format repair: split long lines per the rules and join split lines back when a file is read. A validator should tell you the line numbers, since these faults hide inside long records.

Fault 7: Custom Tags From One Program

Programs may add their own tags, marked with a leading underscore. Custom tags are legal. The file does not fail because they exist. It fails in a softer way: the next program does not know them and drops the data they hold.

Validators list unknown tags as warnings or info. Read that list before you switch programs. It is a map of what you stand to lose. If a custom tag holds a key fact — a military service note, a cause of death — copy that fact into a standard note before you move. After the move, check that the copies arrived.

Fault 8: Facts That Cannot All Be True

The last class is not about form at all. The file is legal, line by line, yet the facts clash. A mother is listed as younger than her child. A marriage is dated after a death. The same event has two dates in two records. These are research problems that a strict export brings to light, often for the first time.

Treat these warnings as gifts. They mark the spots where your tree needs a human look. Fix them in your main program, where the full record and sources are in front of you, then export again. Do not fix facts inside the file by hand unless you also fix them in the program, or the next export will bring the clash back.

How to Fix a File, Step by Step

1. Export a fresh copy. Work on a new export, not the file that failed months ago.
2. Run validation and save the report. The free plan on GedConvert gives you the full report. Keep it next to the file.
3. Fix errors from the top down. Header first, encoding second, links third. Counts often drop fast.
4. Separate format faults from fact faults. Format faults — header, encoding, line splits, IDs — can be repaired in the file. Fact faults — dates that clash, double persons — belong in your research program.
5. Use the repaired file for format fixes. On paid plans, GedConvert writes a repaired file that fixes format only and changes no facts, with a list of what changed. The plans are compared on the pricing page.
6. Re-validate the repaired file. A clean report, or a short list of fact warnings you accept, is the goal.
7. Import into a new, empty tree and compare counts. People, families, and sources should match the report.

What a Repair Will Not Do

Be clear about the limits, because they protect you. A format repair will not invent a missing record. It will not guess which of two dates is right. It will not merge two records into one person. It will not restore a cut file. Any tool that offers to "fix" facts on its own is offering to change your research without your judgment. The right split is simple: machines fix form, people fix facts.

Frequently Asked Questions

My program exported the file, so why is it invalid? Programs store data in their own form and write GEDCOM as a second step. That step is where faults enter: loose dates written as-is, custom tags, long lines left unsplit. The tree in the program and the file on disk are two different things.

How many errors is too many? There is no magic number. A file with three header errors can be worse than a file with three hundred date warnings. Fix errors first, then judge the warnings by whether the facts matter to you.

Will an invalid file still import? Often, yes. Programs differ. Some stop at the first error. Most skip bad lines and keep going, which is more risky: the tree looks whole but is not. Validate first so you know what the import will face.

Should I fix the file or fix my tree and re-export? Both, by kind. Fix fact problems in the tree and re-export. Use file repair for format problems, above all when you no longer have the program that made the file.

What is the single most common cause of failure? Dates written as free text are the most common bulk error. Encoding mismatch is the most common cause of a total refusal. Header faults are the least common and the most damaging per line.

Does GEDCOM 7.0 fail less often? It removes whole classes of faults: one encoding only, no line length limit, a tighter date grammar. Files made fresh under 7.0 rules tend to validate clean. Files converted in a rush can carry their old faults with them.

References

• https://gedcom.io/ — The home of the GEDCOM standard, with the 7.0 and 5.5.1 specs that validation checks against.
• 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.