Which Parts of Your Family Tree Survive a GEDCOM Export?

You are switching genealogy programs. You export your tree from the old one as a GEDCOM file, you open that file in the new one, and it works. All four thousand people are there. The surnames are right. Your great-grandmother is still attached to the correct husband.

Six months later you go looking for the note you wrote about why the second John Kelleher was not your John Kelleher. The note is gone. So is the flag you put on a marriage date you were not sure about. So, it turns out, are the twelve source citations you spent an evening formatting.

Nothing failed, and no error message appeared, because as far as the file format is concerned nothing went wrong.

The short answer. A GEDCOM export carries the standard structures faithfully and carries almost nothing else. The FamilySearch GEDCOM 7 specification states the rule directly in its section on extensions versus standard structures: "Data contained in extension tags will not be interpreted by other systems correctly unless the other system supports that particular extension." Everything your program offers that the standard does not define, which is most of the features you chose it for, is written as an extension tag if it is written at all, and the receiving program is under no obligation to understand it. GEDCOM 5.5.1 is the more compatible target and the lossier one, because it cannot represent structures that version 7 added. No vendor publishes a fidelity table showing what its own export drops. So the only reliable way to know what you would lose is to export, re-import into the destination, and compare one person you know by heart.

The specification warns you about this in writing

Most writing about GEDCOM treats data loss as a rumour, something that happens to other people who used badly built software. It is neither a rumour nor a bug. The specification spells it out, and it follows from how the format was designed.

FamilySearch GEDCOM version 7, the current standard, is built around a fixed vocabulary of standard structures: the tags for an individual, a family, a name, a date, a place, a source citation, and so on. Anything outside that vocabulary has to be expressed as an extension tag, which the specification defines as a tag beginning with an underscore.

Section 1.5.3 of the specification, headed "Extension versus Standard", opens with the sentence that ought to be on the export dialog of every genealogy program ever written: "Standard structures take priority over extensions. Data contained in extension tags will not be interpreted by other systems correctly unless the other system supports that particular extension."

That is the whole problem in one line, and it is stated by the people who wrote the format.

Why this is not a flaw anyone can fix. A standard can only define what its authors agreed to define. Every genealogy program then competes by adding things the standard does not have: a confidence rating on a fact, a to-do list, a research log, a DNA match, a colour-coded ancestor group, a proof argument. Those are the features you compare products on. None of them is in the standard vocabulary, so none of them has a defined way to cross between two programs. The better your program is at the thing you bought it for, the more of that thing is riding in extension tags.

Some extensions are salvageable and some are not

The specification splits extensions into two kinds, and which kind yours are decides whether anyone on the receiving end can work out what your data meant.

A documented extension tag is one the file explains. It is mapped to a URI in a schema structure, declared in the file's own header under the SCHMA tag, and it is that URI rather than the tag itself that carries the meaning. The specification goes further and recommends that whoever invents an extension use a web address as the URI, and publish a machine-readable description of the extension at that address, in a registry FamilySearch maintains for the purpose.

An undocumented extension tag is one the file does not explain. It has no URI in the schema, so its meaning can only be guessed from the tag and whatever structure it sits inside. The specification's advice here is one sentence long: applications should not use them.

What the difference looks like in practice. A documented extension describes itself. The receiving program may not support it, but it can still tell what the data was, and so can a human who follows the URL. An undocumented extension is a line of text with an underscore in front of it and no way for anyone to recover what it once meant. So if you open your own exported .ged in a text editor and find underscore-prefixed tags with no matching SCHMA block in the header, you are looking at data that is already effectively lost, in a file you have not even sent anywhere yet.

This is the single cheapest check in this article and it takes about thirty seconds.

What travels, and what rides in an extension

If you want the short version of which parts of a family tree a GEDCOM export carries, it is the parts the standard has a structure for. Everything below is a standard GEDCOM 7 structure, taken from the specification's own list, and everything marked "none" has no defined structure at all, which means it goes out as an extension or does not go out.

Read the bottom half of that table again, because it is the half people are surprised by. A to-do list, a research log, DNA matches, colour coding and saved hints are five of the features most heavily advertised by the big platforms, and the standard has no structure for any of them. That is not a criticism of those features. It is the reason they cannot follow you out of the door.

The top half should reassure you. Your names, dates, places, sources, notes, associates and the confidence you attached to your evidence all have somewhere defined to go. If those are what your research is made of, a GEDCOM export is a real escape hatch rather than a token one.

5.5.1 is the compatible choice and it is the lossy one

Most export dialogs ask you to pick a GEDCOM version. The advice you will read everywhere, including in our own documentation, is that GEDCOM 5.5.1 is the safer pick because more programs can read it. That advice is correct. What it leaves out is that you are making a trade.

Version 5.5.1 predates version 7 and cannot represent structures that version 7 added. So exporting to 5.5.1 is not simply writing an older dialect of the same thing. It is a conversion, and a conversion from a larger vocabulary to a smaller one drops whatever does not fit.

You are choosing which risk to take. Pick version 7 and you keep the fuller structure, but the destination program may read the file only partially, or refuse it. Pick 5.5.1 and the file will almost certainly open, but some of what you exported was already converted or discarded on the way out. Neither choice is wrong. The problem is that the dialog rarely mentions the trade at all, so most people accept the default and never find out what it cost them.

Nobody publishes a table of what their export drops

This is the part where a guide like this would normally give you a comparison table of eight programs and what each one loses. We are not going to, because as far as we could establish, that table does not exist anywhere, and inventing one would be worse than admitting the gap.

We searched for it in September 2026. The closest thing the open web has to an answer is a question: a Genealogy Stack Exchange post titled "How Complete is GEDCOM Export from Various Programs?" Everything else on the first page was a forum thread, a Reddit discussion, a Facebook group post, a help-desk article about exporting with and without media, and a handful of explainers about what a GEDCOM file is. Not one of them tested a single program.

The gap is structural, not suspicious. Such a table would have to be re-tested for every new version of every program, and for a vendor it would amount to publishing a list of its own product's shortcomings in a format built for side-by-side comparison. No vendor has a commercial reason to write it, and no neutral body is funded to maintain it. Waiting will not fill it.

So treat any claim about what a specific named program loses on export, including anything you read in this article, as unverified unless the writer says they tested it and says when. Versions change. A behaviour that was true in 2022 is a guess in 2026.

How to test your own software in twenty minutes

Nobody is going to write that table, so write the one row of it that applies to you. The procedure below works whichever two programs you are moving between.

Pick one person you know by heart. Do not pick a typical person. Pick your most heavily documented one: someone with alternate spellings of their name, four source citations, a note explaining a conflict, a photograph attached, an uncertain date, and whatever your program's headline feature is applied to them. A sparsely documented person will pass every test and teach you nothing.

Write down what you expect, before you export. Ten to fifteen specific items, listed on paper or in a file outside the program. Not "her sources" but "the 1901 census citation with the page reference in it". Write the list first, because if you write it afterwards you will unconsciously shape it around whatever survived.

Export, then open the .ged in a plain text editor. A GEDCOM file is plain text, so you can read it yourself. Search it for each item on your list. Anything you cannot find in the file was dropped on the way out, before the destination program was ever involved. While you are in there, check the header for a SCHMA block and count the underscore-prefixed tags in the body. That count is how much of your research is riding on extensions.

Then import the file into the destination program and check the same list again. Anything that was present in the file but is absent in the destination was dropped at the import step. That distinction matters, because the two failures have different fixes: an export-side loss means you need a different export format or a different route out, while an import-side loss sometimes means the destination has an option you did not tick.

Do it in both directions if you can. Export, import, then export again from the destination and compare the two files. A round trip is the strictest test there is, and it is the one that catches the quiet cases where data survives the transfer but changes meaning.

Twenty minutes on one person will tell you more than any published comparison could, because it tests the two programs you actually use, at the versions you actually have, against the research you actually care about. If you want to understand what you are looking at inside the file, the structure is explained in how to move a family tree with a GEDCOM file.

Portability is a feature, and nobody compares it

When people choose genealogy software, they compare record collections, price, interface and platform. Our own comparison of ten genealogy tools is organised the same way, because those are the things buyers actually weigh.

Portability almost never makes that list. It is also the one feature whose absence you find out about at the worst possible moment: the day you decide to leave, or the day the company shuts the product down. A tree is usually the work of years, and the notes and reasoning attached to it are often worth more than the names themselves, because the names can be found again and the reasoning cannot.

Ask two questions before you commit to any platform. Can you export everything yourself, whenever you want, without emailing support to request it? And does that export include the things you spend your time on, meaning your sources, your notes and your images, rather than only the skeleton of names and links? A platform that answers yes to the first and no to the second has given you a tree you can move and a body of research you cannot.

What KleioBase does on export, and what it does not

Disclosure, since we sell a tool.

KleioBase is a research companion that turns scattered historical records into one connected family archive, which means the tree is not the only thing at risk on export. So is the data extracted from your records, the different spellings a person appears under from one document to the next, the associates, and the searches you recorded as having found nothing.

Export is available on every plan, including the free one, and the dialog lets you choose between GEDCOM 7 and GEDCOM 5.5.1.

The file carries more than names, dates and family links. It also carries the other names a person is recorded under, associates such as witnesses, godparents and officiants, place coordinates for the places we have mapped, a profile photo where one is set, and the searches you recorded as negative evidence. Dates written in the Hebrew, Julian or French Republican calendar go out in the calendar the record used, rather than being silently converted to the Gregorian. All of those are read back on import too, so a tree that leaves and comes home keeps them.

Two options sit under the format choice. You can bundle your record images into the file or export the text tree on its own, and a "Redact living people" checkbox, off by default, leaves living relatives' details out while keeping them in the structure so the tree stays connected.

The negative-evidence searches are worth singling out, because they are this article's own argument applied to us. GEDCOM 7's non-event structure, NO, states that an event did not happen in a given period, and the specification forbids anything under it from narrowing that claim. "Not in the Kalisz register for 1889 to 1900" is a weaker statement than "did not marry between 1889 and 1900", so writing a search result as NO would put words in your mouth. An entry you recorded as never having happened at all does go out as NO. A dated search goes out as a documented extension, declared with its own URL in the file's SCHMA header, so KleioBase reads it back in full and any other program can at least tell what it was. That is the trade this article describes, made deliberately rather than by accident.

Now the honest limits. Three of them.

First, when you export to 5.5.1, our converter maps the document down from version 7 and records every item it had to change or drop. The export email then reports how many items that was. It does not tell you which ones. You get a count where you need a list, and a count is not something you can act on. That gap is ours, and it is the same failure this whole article is about: knowing that something did not survive is not the same as knowing what.

Second, nothing about choosing GEDCOM 7 guarantees the destination reads it. The standard being newer and better specified does not make any particular program implement it, and we cannot test every destination.

Third, a GEDCOM export is the family tree and only the family tree. Your record transcriptions and your research companion conversations are not in it. A separate full data download covers those, and the two exports exist for different jobs.

Where to start, on a tree you already have

Do the twenty-minute test this week, on whatever program currently holds your research, while you still have no particular reason to move. Far better to learn the answer now than on the day you need it.

Then fix the cheapest failure first. If your notes are not travelling, the fix is usually a habit rather than a new program: put the reasoning that matters into the fields the standard defines, instead of into whichever proprietary panel your program offers for it. Sources, notes and citations are standard structures, and they travel. A custom flag on a custom tab is an extension, and it does not. Writing down what disagreed and what came up empty, somewhere that can actually leave with you, is worth doing whether or not you ever change software, and the evidence layer your research log is probably missing makes that case at length.

This matters most on the families where the records are thinnest. When there are three documents and a chain of inference connecting them, that chain is not an annotation on the research. It is the research. Losing it silently, in a file that opened without a single error, is the worst way there is to discover it was never portable.

The people who wrote the first version of GEDCOM in the 1980s were solving a transfer problem between programs that recorded names, dates and links, because that was what genealogy software did at the time. Everything else got bolted on outside the standard afterwards, one vendor at a time, and the standard has been telling anyone who read section 1.5.3 exactly what would happen to it.