We ran every GEDCOM file in a public, openly licensed test corpus through our own parser and validator. Thirty-six files, the ones that genealogy software gets tested against. The point was to find out what is actually wrong with real files, rather than what the specification says should be in them.
Two things to be straight about before any of the numbers. These are public test files, not files belonging to our users, and we would not run anybody's family data through a survey like this. The free tools on this site do their work inside your browser and never upload your file anywhere. And thirty-six is a small number that includes synthetic fixtures and deliberate torture tests, so nothing below is a percentage or an average. It is a list of named files and what each one contained.
The oldest file in the set was written in November 1992 and never says which version it is.
The file is royal92.ged, a royal lineage of 3,010 people across 1,422 families. Its header is a short history lesson. The source program is PAF 2.2, Personal Ancestral File, software from the early 1990s. The date is 20 November 1992. The character set is ANSEL, a library cataloguing standard that Unicode long ago replaced everywhere else. And there is no version block at all, so the file never declares whether it is GEDCOM 5.5, 5.5.1 or anything else. A parser has to guess.
It is still in the corpus that people test modern genealogy software against, thirty-four years later. That is the shape of this whole field. Files outlive the programs that made them by decades, which is the strongest argument for checking what is in yours rather than assuming.
The 2020 export had more contradictions than the 1992 one.
You would expect the 1992 file to be the worst. It is not. Setting aside the deliberate torture tests and the unrecognised-tag findings, the real tree with the most flags per person is bullinger.ged, 948 people, exported from Gramps 5.0.1 in January 2020. Our validator raised 18 possible duplicate individuals, 13 children recorded as born before a parent, 8 dates it could not read, and 2 people who died before they were born.
The 1992 file had the same faults in smaller numbers: 8 possible duplicates, 4 children born before a parent, 1 death before birth. Different decade, different program, same list. But we opened the records, and the raw counts flatter the problem in a way worth spelling out. Seven of those 13 impossible birth orders are children of one woman whose record reads born 1886, died 1746, which is plainly 1686 mistyped. Two more trace to a single truncated year, written as 23 JAN 187. Thirteen flags, two bad keystrokes.
That is the useful shape of it. One wrong digit does not produce one error, it produces a cluster, because every child of that parent now looks impossible. Finding the cluster is how you find the typo. These are not toy files either. The 1992 export holds 3,010 people across 1,422 families, which is larger than most trees anyone reading this will have built, and the Gramps file holds 948 people across 343 families. Both are the size at which you stop being able to eyeball the data and start needing something to check it for you. That is roughly the point at which a duplicated great-grandmother stops being obvious and starts quietly splitting her sources in two.
The encoding check found a bug in our own validator.
All four torture-test files in the corpus declare ANSEL, a character set that predates Unicode. Two of them separate lines with a carriage return alone, the convention Macs abandoned around 2001. Our own encoding detector looked for the character-set line after a newline, so on those two it found nothing and fell through to assuming UTF-8, while the rest of the parser read the ANSEL declaration correctly. The two halves of our own tool disagreed with each other.
That is a real bug rather than a quirk of old test files. Any GEDCOM saved with classic Mac line endings and a non-Unicode character set would have had every accented name and place mangled in our viewer. We found it by writing this post, fixed it, and added a test so it cannot come back. The files were fine. We were not.
The wider point survives the correction. ANSEL is a library cataloguing standard almost nothing outside bibliographic systems still emits, and it is sitting in the header of a 3,010-person family tree. Elsewhere in the set are files from LIFELINES 3.0.62 declaring cp1252 and tagged as French. Every one of those declarations is a chance for the next program to guess wrong, which is the mess GEDCOM 7 set out to end by mandating UTF-8 and nothing else, as we covered in what a GEDCOM leaves behind.
Unrecognised tags turned up in nearly everything.
The most common finding by a wide margin was a tag our parser did not recognise, and it appeared in files from every program in the set. Fourteen in a MyFamilyTree export of British royalty, seven in a MyFamilyTree Kennedy tree, thirty-five in a tooling assessment file, forty in each torture test. Vendors invent tags for the things the specification has no word for, by convention prefixed with an underscore, and everyone invents different ones.
This is the least alarming finding on the list and the most universal. An unknown tag usually means a feature of the program that wrote the file, not corruption. It matters only when you move the file somewhere that quietly drops it.
Exactly one real tree came back clean, and it is the smallest.
Of the genuine exports, one had nothing flagged at all: a 31-person Shakespeare family tree. Everything else with real people in it had something. We are not going to dress n equals one up as a trend, but it points the same way as the rest of the set. Problems scale with size and with the number of programs a file has passed through, not with the care of the person who built it. A small tree that has lived in one program is the easiest thing to keep clean, and almost nobody has one.
What each kind of flag actually means.
Possible duplicates: two records that share a name and a near-identical birth year. Sometimes that is the same person entered twice after a merge, splitting their sources across two records. Often, in the Bullinger file especially, it is not: it is a family that reused a name when a child died young, or two cousins named after the same grandparent. The check cannot tell those apart, which is why it says possible. Child born before a parent: usually one typo, multiplied across that parent's children. Unreadable dates: a partial or non-standard date no parser can turn into a real one, so it quietly stops being sortable. Death before birth: two transposed digits. Unknown tags: a vendor feature with nowhere standard to live.
Every one of those is findable in a minute and fixable in ten. None of them announce themselves, because your genealogy program will happily store all five without a word of complaint.
If you want to run the same check on your own file, that is what our GEDCOM validator does, using the same rules we ran here, in your browser and without uploading anything. The GEDCOM viewer shows you what is inside the file, and our guide to opening a GEDCOM file explains the format if the header above looked like another language.
One honest limitation worth stating. Our validator's rules are tuned for GEDCOM 5.5.x, so we excluded the eleven version 7 files from every count above. They parse fine, but they raised large numbers of flags that measure how far our rules have followed the newer standard rather than anything wrong with the files.
