Why the Mormon Church created GEDCOM — and why it still controls the format

Open almost any family tree file in the world and you'll find the same format: GEDCOM. Ancestry exports it. MyHeritage imports it. Every desktop genealogy program on the market reads it. It is the closest thing family history has to a universal language.

It was not built by a software company, a university, or a standards body. It was built by The Church of Jesus Christ of Latter-day Saints, and it was not built to help you organise your hobby. It was built so church members could submit the names of dead people for temple ordinances.

That origin is not trivia. It is still visible inside the file format you use today.

Why Latter-day Saints needed a genealogy data standard

For most people, family history is a pastime. For faithful Latter-day Saints it is a commandment with eternal consequences — and that distinction is the whole reason GEDCOM exists.

Church teaching holds that saving ordinances — baptism, confirmation, the endowment, sealing — are required for exaltation, but that billions of people died without receiving them. The solution is proxy ordinances: living members perform these rites in temples on behalf of named deceased individuals, who may then accept or reject them in the spirit world.

Three scriptural anchors are cited constantly:

• 1 Corinthians 15:29, Paul's question about those “baptized for the dead,” is the New Testament proof text. (Biblical scholars outside the LDS tradition generally read this as Paul referencing a practice rather than endorsing it, and as an argument for resurrection rather than an instruction. The Church reads it as evidence the practice is ancient.)
• Doctrine and Covenants 128, an 1842 letter from Joseph Smith, is the doctrinal core — and it is explicitly about record-keeping. Baptisms for the dead must be witnessed and certified by recorders, because “whatsoever you record on earth shall be recorded in heaven.” Verse 15 teaches that the living and their dead cannot be made perfect without each other. This is, functionally, a theology of data integrity: the accuracy of the record carries salvific weight. The Church's own teaching materials note that early baptisms which were not properly witnessed and recorded had to be performed again.
• Malachi 4:5–6, the prophecy that Elijah will turn the hearts of fathers and children to one another, is treated as the mandate for family history work. Latter-day Saints believe it was fulfilled when Elijah appeared to Joseph Smith in the Kirtland Temple on 3 April 1836.

Layer on the doctrine of eternal families — sealing spouses to each other and children to parents forever — and the practical requirement becomes obvious. You cannot seal a family you cannot accurately reconstruct. Duplicate or erroneous records mean wasted ordinance work.

No other organisation on earth has that combination: a theological reason to want everyone's genealogical data to be accurate, complete, and interoperable, plus the money to pursue it for over a century.

The record-gathering machine behind GEDCOM

GEDCOM did not appear from nowhere. It was the software layer on top of an industrial-scale record-gathering operation that was already ninety years old.

The Genealogical Society of Utah (GSU) was organised on 13 November 1894 in the Church Historian's Office under church president Wilford Woodruff, with Franklin D. Richards as its first president. It was set up as a nonprofit — legally separate from the Church but funded by it — to help members, many of them recent European and British immigrants, trace their ancestors.

It's worth keeping three names straight, because sources use them interchangeably:

Record collection scaled with technology. The GSU began microfilming in the United States in 1938, ran its first large out-of-state project in Tennessee in 1939, and went international after the Second World War. By the early 1950s the collection had passed 100,000 rolls, which created a storage problem.

The answer was the Granite Mountain Records Vault, cut into solid rock in Little Cottonwood Canyon southeast of Salt Lake City — the same canyon that supplied stone for the Salt Lake Temple. Built between 1958 and 1963 at a cost of around $2 million, the excavation reaches roughly 600 feet into the canyon wall, with the vault itself sitting under about 700 feet of stone across six chambers. It is climate-controlled for long-term preservation and holds on the order of 2.4 million rolls of microfilm — roughly three billion pages — from more than 100 countries.

The modern numbers explain why a data interchange format became unavoidable. FamilySearch reported passing 20.5 billion searchable records and images in 2024, with a shared Family Tree of 1.67 billion people. By the end of 2025 that had grown to more than 22.7 billion records and a tree of 1.8 billion people. The public library at Temple Square, dedicated in October 1985, was renamed the FamilySearch Library in January 2023.

All of it began as machinery for identifying the dead so their ordinances could be performed.

Who created GEDCOM, and when

GEDCOM stands for GEnealogical Data COMmunication. It was developed by the Church's Family History Department — the same institution as the GSU and FamilySearch — starting in 1984.

The founding date is genuinely disputed, and you'll see different answers depending on what counts as a “release”:

The GEDCOM 5.4 specification itself states that versions 1 and 2 were drafts for public discussion and were never established as a standard. Byron Clark, credited with much of the early technical work, has described the tag-hierarchy design as adapted from an earlier database technology, and places the first GEDCOM Developers' Conference — where roughly thirty attendees received version 1.0 — at the Family History Library in 1985. FamilySearch generally cites 1984. All of these can be defensible; treat any single date with caution.

How GEDCOM escaped the Church

The mechanism that turned an internal church format into an industry standard was free software plus a submission requirement.

Personal Ancestral File (PAF), the Church's free genealogy program, arrived in the mid-1980s and exported GEDCOM. Those files fed TempleReady, the program at Family History Centers that checked submitted names against the International Genealogical Index — a database of already-completed ordinances that passed 347 million names by around 2001 — to prevent duplicate temple work, then packaged cleared names for the temple.

Critically, TempleReady accepted GEDCOM files from any genealogy program, not just PAF. That gave every commercial vendor a hard commercial reason to support the format: their Latter-day Saint customers needed it to do temple work. Support GEDCOM or lose that market.

From there it spread by default. PAF was discontinued on 15 July 2013, long after the format it seeded had outgrown it.

The LDS ordinance tags hiding in every GEDCOM file

A GEDCOM file is plain text organised into numbered, hierarchical lines with short tags. Most are universal: INDI for an individual, FAM for a family, BIRT, DEAT, MARR, NAME, DATE, PLAC. (For a line-by-line walkthrough of that grammar, see the GEDCOM format in plain English.)

But an entire category of tags exists solely to record Latter-day Saint temple ordinances, and they have been in the standard since the late 1980s:

Each ordinance carries sub-tags for date, temple, place, and status — because this data was designed to be processed by temple systems, not merely displayed on screen.

A telling quirk: the child-sealing structure was moved from FAM.CHIL.SLGC to INDI.FAMC.SLGC, and for a period developers were advised to write the data in both locations so PAF and third-party programs would stay compatible. Ordinance processing was driving technical design decisions in a format used worldwide.

The submission record: a religious workflow inside a file format

The clearest fingerprint is the SUBN submission record. The specification says plainly that it was created for the TempleReady system and for files downloaded from Ancestral File. Its fields include:

• ANCE — how many generations of ancestors to process
• DESC — how many generations of descendants
• TEMP — the family file name under which names are stored at the temple
• ORDI — a flag indicating whether the submission should be processed for temple ordinance clearing

That is not a genealogy feature. It is a religious workflow control record embedded in a global data standard.

Two identifiers tell the same story: AFN (Ancestral File Number, the permanent ID in the Church's Ancestral File database) and RFN (Record File Number). Technology writer Tamura Jones has argued these should have been vendor extensions prefixed with an underscore rather than core standard tags, since they duplicate the general-purpose IDNO. GEDCOM 7 effectively conceded the point.

Most users of Ancestry, RootsMagic, or MyHeritage will go their entire genealogical lives without knowingly writing a BAPL or SUBN line. The tags are there regardless.

Twenty years of stagnation: the draft that lasted until 2019

This is where the wider genealogy community's frustration comes from, and it's justified.

The permanent draft. GEDCOM 5.5.1 was issued on 2 October 1999, adding nine tags (including WWW, EMAIL, FACT) and — importantly — UTF-8 as an approved encoding. It was stamped “draft.” It stayed a draft for twenty years.

That single word caused real damage. Cautious developers stuck with 5.5; others implemented parts of the draft inconsistently. Real-world GEDCOM files diverged. Meanwhile FamilySearch used 5.5.1 internally and in PAF while the cover page told everyone else not to rely on it. Only on 15 November 2019 did FamilySearch quietly reissue the document with “draft” removed and the copyright dates updated. As Tamura Jones documented at the time, essentially nothing else changed — it was the same 1999 text with a label removed two decades late. Louis Kessler and others made the same observation.

One small detail from that 2019 update: the working link to the list of temple codes in Appendix B was replaced with a note that it was no longer available — an early sign of LDS-specific content being quietly wound down.

Failed replacement #1: GEDCOM 6.0 (2000–2002). An XML-based successor, released as a beta on 6 December 2002. Never finished. Abandoned.

Failed replacement #2: GEDCOM X (2012). Unveiled at RootsTech 2012 by FamilySearch's Jay Verkler as a new industry standard, with an open data model and XML and JSON serialisations. Within months the project was repositioned: it was not vendor-neutral, and FamilySearch's own needs came first. That admission destroyed its credibility as a community standard. GEDCOM X still exists — it underpins the FamilySearch Family Tree and its API — but it never replaced GEDCOM for moving files between programs.

The community did not sit still. BetterGEDCOM, a wiki-based effort, grew into the Family History Information Standards Organisation (FHISO), launched at RootsTech 2012 with founding members including Ancestry and RootsMagic, hoping to become a genuinely neutral standards body. It never merged with FamilySearch's efforts. Separately, Tamura Jones published GEDCOM 5.5.5 in 2019 as an independent cleaned-up specification (strict UTF-8, a sex value beyond M/F, and other fixes), alongside an annotated edition of 5.5.1 produced with input from nine working developers to pin down the ambiguities.

GEDCOM 7 and who controls the standard in 2026

At RootsTech 2020 FamilySearch tried again — this time with outside collaboration. Luther Tychonievich, a University of Virginia computer scientist who was also FHISO's chair, served as managing editor, with contributors including Tony Proctor and others from the BetterGEDCOM/FHISO world.

FamilySearch GEDCOM 7.0 was released in early June 2021 (7.0.2 followed on 15 June). The improvements were real:

• Mandatory UTF-8 throughout
• GEDZIP — a zip package bundling data with media files, finally solving broken photo links
• Expanded, styleable notes
• Removal of long-standing ambiguities
• Semantic versioning and a public GitHub repository

Governance today. FamilySearch still owns the standard, but the terms have loosened considerably. The specification is published under the Apache License 2.0, copyright Intellectual Reserve, Inc. (the Church's IP holding company), with “FamilySearch GEDCOM” as a trademark. A FamilySearch GEDCOM Steering Committee of roughly six members handles issues and pull requests on the public repo, supported by project teams — including one working on the Western-centric name structure. Maintenance releases are steady; the specification reached 7.0.18, dated 17 February 2026.

Compare that with the old model, where the spec granted permission to copy only for reviewing or programming genealogical software. It's a meaningful improvement. It is still single-organisation control.

Adoption: the reality check

This is the part that actually affects your files. GEDCOM 7 uptake has been slow and patchy.

FamilySearch maintains an implementation progress list of roughly three dozen companies committed to adoption — but “committed” is not “shipped,” and several major names carry TBD dates.

Shipped support exists in Family Historian (2023), MacFamilyTree 10 (an early adopter, February 2022), Ancestris (2024), Reunion 14 (2024), and Heredis (import only, 2023), plus a cluster of smaller, often German, tools and validators.

Partial or in progress: Gramps has support in active development, with open tag issues still being worked through in mid-2025. webtrees core still targets 5.5.1, with GEDCOM 7 available only via a third-party module. RootsMagic 9 can import GEDCOM 7, but its official documentation still describes 5.5.1 export.

Not shipped: As of 2026, neither Ancestry nor MyHeritage offers GEDCOM 7 export. Ancestry has signalled future support without a confirmed launch; MyHeritage lists no date. (The Ancestry and MyHeritage export guides cover what you do get.)

Louis Kessler summed up the pace in 2023: more than two years on, very few developers had implemented it. The consequence is blunt — GEDCOM 5.5.1 is still the real-world lowest common denominator, a quarter-century after it was drafted.

Be sceptical of third-party compatibility charts, incidentally. Several overstate support; claims of full GEDCOM 7 support in RootsMagic and Ancestral Quest are not corroborated by those vendors' own documentation.

Do the LDS tags survive in GEDCOM 7?

Yes — pruned and modernised, but present.

What stayed. BAPL, CONL, ENDL, SLGC, SLGS, and TEMP all survive, gathered under a Latter-day Saint Ordinances section of the specification. GEDCOM 7 even adds sensible constraints — ordinance dates must be Gregorian and 1830 or later, since the Church was organised in 1830.

What changed. The old WAC washing-and-anointing tag was replaced by INIL (the initiatory ordinance), cleaning up a long-standing mess where PAF, the spec, and third-party programs using _INIT had never agreed.

What was removed. The SUBN submission record and its AFN/RFN machinery are gone. FamilySearch's migration guide is direct about why: these structures were specific to Ancestral File and TempleReady, and those systems are no longer in use. The Ancestral File Number now survives only as an external identifier (EXID with a FamilySearch-defined type URI) to support converting old files.

That split is the clearest signal of where the format is heading. The parts tied to 1990s church software are gone. The parts describing ordinances the Church still performs remain.

How software handles them. LDS-oriented programs like Ancestral Quest read and write these tags fully. Mainstream programs generally preserve them on import and export but hide them from non-LDS users — or silently drop them. Because they are part of the standard rather than proprietary extensions, a well-behaved reader is supposed to carry them through untouched. That's why you may open a stranger's GEDCOM one day and find temple codes and sealing dates you have no use for.

Should one church own the genealogy standard?

The criticisms are fair and long-standing:

• Single-organisation control. When FamilySearch neglected GEDCOM for two decades, the entire field froze. When it announced GEDCOM 6.0 and GEDCOM X and then walked away from both, it burned developer trust — Jones and others have catalogued the pattern.
• Draft limbo. The 1999–2019 gap produced years of incompatible implementations and the persistent complaint that sources, notes, and media don't survive a round trip between programs.
• Licensing. Even the liberalised 7.0 spec is copyrighted by a church-owned entity and granted by one owner, rather than governed by a neutral multi-vendor body like FHISO.
• Values friction. Some critics, including LGBTQ genealogy advocates, object to a standard controlled by an institution whose doctrines they consider exclusionary, and note that relationship and sex modelling reflects contested choices. GEDCOM 7's FAM documentation now explicitly states the record can represent adoption, cohabitation, fostering, and same-gender partners; the independent 5.5.5 fork went further by adding an X sex value.

And yet the counter-argument is hard to dismiss. Without the Church, there might be no universal genealogy interchange format at all. No commercial vendor had any incentive to give away a free open format that makes it easy for customers to leave. A university project would likely have died with its funding. It took an organisation with a theological reason to want universal interoperability — and the patience to fund it for forty years — to build GEDCOM and keep it alive.

For all its flaws, it remains the only universal genealogy data transfer mechanism that exists. The doctrine of gathering the dead is, unexpectedly, the reason you can move your grandmother's data from one app to another.

What this means for your files

Practical takeaways for anyone actually moving data in 2026:

1. For maximum compatibility, export as GEDCOM 5.5.1 — especially if the destination is Ancestry, MyHeritage, or Family Tree Maker. Some even reject a “5.5.1” version string and expect “5.5”. GEDCOM 7 is the better format; the biggest sites still can't read it.
2. Use GEDCOM 7.0 with GEDZIP for archiving and for transfers between programs that support it. That's where you get UTF-8, bundled media, and citations that survive the trip.
3. Always verify a round trip. Export, re-import into a second program, and check that sources, notes, and media survived. Silent data loss on transfer is GEDCOM's historical weakness — the validator catches the structural half of it (dangling pointers, one-way family links, impossible dates) before an import does, and a spreadsheet export of both files makes a before/after comparison easy.
4. Don't strip BAPL, ENDL, SLGC, SLGS, or TEMP lines from files you receive. They are valid standard data — someone's temple ordinance records — and a good tool preserves them even if it won't display them.
5. Watch two signals that would change this advice: the day Ancestry and MyHeritage ship GEDCOM 7 export, and any move of the standard from FamilySearch's sole control to a neutral multi-vendor body.