Monday, June 7, 2021

The Long-Awaited GEDCOM 7.0 is Here!

 FamilySearch has released GEDCOM 7.0 to the genealogy world in an announcement today:


FamilySearch International is pleased to announce the release of FamilySearch GEDCOM 7.0 (Genealogical Data Communications). The latest version allows zip packaging capabilities for photos and files with genealogical information, plus new tools, and a public GitHub repository for ongoing maintenance. Technical information, specifications, tools, and guides can be found at

At RootsTech 2020, FamilySearch launched an effort to create a new version of GEDCOM based on the 5.5.1 version that would include: 1) new expressivity, flexibility, and compatibility; 2) zip packaging of associated images and other files with the related GEDCOM file; and 3) public access using a GitHub repository. Many industry software providers and key influencers participated, and the initiative concluded May 15, 2021, with the completion of this comprehensive effort.

FamilySearch GEDCOM 7.0 is the outcome of those efforts and includes the following new enhancements:

Zip packaging capabilities for photos and files have been added.
Notes have been expanded for more versatile use and styling of text.
Tools, sample files, sample code, and self-testing guides are included.
The GEDCOM specification and any code available from FamilySearch based on the specification is subject to the terms and conditions of the Apache License, Version 2.0.
Ambiguities in the GEDCOM Version 5.5.1 specification have been removed.
A public GitHub repository generates maintenance requests and on-going discussions about future features.

Users of FamilySearch GEDCOM 7.0 will be able to import files from older GEDCOM versions. However, users of older versions of GEDCOM will not be able to import from FamilySearch GEDCOM 7.0.


There is more information about GEDCOM 7.0 on the FamilySearch page - 

You can find the technical specification for GEDCOM 7.0 in PDF at  

The specification lists the Contributors to this effort, which apparently was organized at RootsTech 2020.  All of the major family tree "players" were involved.  I am glad that there was this much participation and hope that all parties can incorporate this new GEDCOM capability into their programs and websites without destroying the current GEDCOM 5.5 capabilities we've had for the past 20 years.

It will be interesting to see how the new features will be implemented in current software programs and online family trees.

This has been years in the making, since the BetterGEDCOM then FHISO effort from about 2012, FamilySearch building GEDCOM X by themselves, and now, finally, we have an improved GEDCOM  standard.

If I recall correctly, one of the anticipated presentations at RootsTech 2021 was unveiling GEDCOM 7.0.  It was scrubbed before the online virtual conference began.


The URL for this post is:

Copyright (c) 2021, Randall J. Seaver

Please comment on this post on the website by clicking the URL above and then the "Comments" link at the bottom of each post.  Share it on Twitter, Facebook, or Pinterest using the icons below.  Or contact me by email at


Tess said...

I'm curious to see how long it will take the various genealogy software companies to implement this new version of gedcom. More importantly, will Ancestry and the other big genealogy sites do it as well? If they did, it would make the need to sync or TreeShare obsolete, though methinks Ancestry might not want to allow people to include all that media in a gedcom download as it could mean a drop in revenue if people download their docs and don't renew. Then again, people who want just a snapshot, rather than doing continual research are always liable to join, gather what they can in a year, and then never renew.

Interesting indeed...

History Hunter said...

One thing that I wish the GEDCOM 7 Std. had is EVENT tags for entering or leaving a place, but not for the purpose of immigration or emigration. That is; it would be nice to be able to document the many ocean trips that some ancestors took. Right now, one has to create a special event tag, and those don't transfer to other programs. Using the EMIG and IMMI tags gives the wrong impression.

Louis Kessler said...

History Hunter:

If those special event tags are written by your program to GEDCOM as: 1 EVEN 2 TYPE xxx and if the 2nd program would read that properly, then the xxx would be the event name in both the first and 2nd program and everything would transfer correctly.

GEDCOM 5.5.1 (and GEDCOM 7.0) already have that capability. The problem is that either your program is not exporting that correctly, or the other problem is not importing that correctly.

It is important that developers understand what is already in GEDCOM and implement it properly. Most of the reason why data doesn't transfer is not GEDCOM. It's the developers.

History Hunter said...

Thanks for the response, Louis.

I've used an number of the popular programs over the years and no two of them exchange GEDCOM data even close to fully; especially user-defined tags..

There is little incentive for developers to fully handle user-defined tags. As it is; developers only tend to fully handle the pre-defined tags, in order to advertise that they adhere to the GEDCOM standard. Few spend the time to FULLY implement the standard in their software. I suspect that this is because the handling of potentially unusual information from user-defined tags could cause them issues in coding their data-entry screens and formatting and wording generated reports.

This is why, I wish that specific types of information, like that noted in my first post, was issued a pre-defined tag. The noted information is quite prevalent in the research of anyone who had ancestors that travelled for more than immigration and emigration purposes.

Louis Kessler said...

History Hunter: There is no problem handling user-defined tags if the developer would just sit down and think about it. They only need an event with a user-defined name. They could handle it the same as any other event, except instead of naming it "Birth", "Census" or "Divorce" because they are 1 BIRT, 1 CENS or 1 DIV tags, they name it "xxx" because they are 1 EVEN 2 TYPE xxx. They will have dates, places, notes, sources just like the other tags and can be processed similarly to a CENS tag for editing or display purposes.

Adding new pre-defined tags serves only to force more effort on programmer to handle the new tags differently, and they will be less receptive to that than to handling all other tags more generally. GEDCOM needs to be kept as simple as possible for developers. New capabilities should only be added to it there is some necessary data that cannot be represented in it. 100 new event tags does not do anyone any good.

The incentive to developers to handle GEDCOM correctly is that people will use their programs BECAUSE they will know they will be able to get their data in AND out again.