A GEDCOM file is a structured plain-text format that has become the backbone of modern genealogy, allowing family historians to move data between software, safeguard decades of research, and share family trees across platforms.
At its core, GEDCOM solves a very specific problem: different tools store genealogical data in incompatible ways, yet researchers need a common language to exchange information about people, events, relationships, and sources. Understanding how it is structured and how to use it safely is essential for long-term digital legacy planning.
In parallel, newer privacy-first platforms such as MyHeirloom extend beyond GEDCOM’s technical focus to weave genealogical facts together with memories, documents, recipes, and stories. This creates a richer personal archive that can coexist with and eventually integrate standardized tree data.
This guide explores GEDCOM in depth—from its origins and technical grammar to practical workflows, ethical considerations, and how it fits into broader legacy ecosystems like MyHeirloom.
Over the past four decades, genealogy has moved decisively from paper binders and card indexes into the digital world. Family historians now rely on desktop software, web-based platforms, and mobile apps to record individuals, family relationships, sources, photos, and notes.
Each of these systems typically uses its own internal data format—a proprietary language optimized for its particular features and interface. While proprietary formats can be powerful, they create a serious problem: data lock-in.
A family historian may invest years in a single application, only to discover that migrating to another tool or sharing data with relatives requires complex manual re-entry.
GEDCOM—short for Genealogical Data Communication—was developed precisely to solve this interoperability challenge. Designed as a common exchange format, GEDCOM allows genealogical information to be exported from one application and imported into another, functioning as a lingua franca across otherwise incompatible systems.
In practice, GEDCOM serves as both a backup mechanism and a transfer vehicle, letting researchers periodically export their tree as a .ged file to preserve a snapshot of their work. They can use the same file to move data between programs such as Family Tree Maker, Legacy, MyHeritage, or Ancestral Quest.
From the perspective of digital legacy, genealogical facts—names, dates, places, relationships, and source citations—are foundational components of a broader personal archive. A birth date or marriage record is not just a data point; it intersects with stories, photos, recipes, and memories that together form a family’s narrative.
Platforms like MyHeirloom build on this insight by combining genealogy with personal storytelling, multimedia Keepsakes, secure document organization, and intergenerational features such as Family Tree and My Tribe. In the long run, standardized genealogical data from GEDCOM files can complement these richer narrative spaces, providing structured backbone information that supports more context-rich legacy preservation.
It is important to distinguish between GEDCOM as a file format and GEDCOM as an imagined protocol. The acronym historically referred to Genealogical Data Communication, but in technical reality, GEDCOM is not a communication protocol at all; it is simply a structured text format intended for exchanging genealogical data.
A GEDCOM file usually carries the extension .ged and consists solely of lines of plain text, each of which follows a specific grammar. There are no binary blobs, hidden databases, or embedded executable code inside a GEDCOM file, making the format incredibly resilient and readable even decades after creation.
At the same time, GEDCOM is not a complete representation of every aspect of human lives or family relationships. The format focuses primarily on lineage-linked data anchored in a conceptual model of the nuclear family. Individuals are represented in INDI records, families in FAM records, and the relationships between people are expressed through references from individuals to families and vice versa.
More complex relational structures—such as overlapping households, non-binary gender identities, and nuanced social ties—are not expressed with the same richness in traditional GEDCOM versions.
Finally, GEDCOM is not a user-friendly narrative medium. Open a .ged file in a text editor and you will not see a visually pleasing tree or story; instead you will see level numbers, tags, IDs, and values forming a structured outline.
The format was devised as an exchange mechanism between programs, not as a reading experience for humans. That is why applications exist on top of GEDCOM to render, visualize, and extend genealogical data. MyHeirloom, for example, uses its own data models and interfaces for Family Tree, Keepsakes, and DocuVault, but its design is conceptually compatible with the types of data GEDCOM carries.
In contemporary genealogy, GEDCOM serves three closely related purposes. First, it functions as a transfer format. When a researcher moves from one software package to another, they often export a GEDCOM file from the old program and import it into the new one, thereby carrying across individuals, families, events, notes, and source citations.
Major desktop programs, as well as online platforms like Ancestry and MyHeritage, support this workflow because GEDCOM is the de facto standard for interoperable tree data.
Second, GEDCOM acts as a backup format. Because it is plain text, it can be stored, inspected, and migrated across systems with relatively low risk of obsolescence compared to proprietary binaries.
Researchers sometimes keep periodic GEDCOM exports as snapshots of their work, knowing that even if a particular software vendor disappears, other programs will likely still be able to read GEDCOM decades later. This archival role is especially important in the context of digital legacy planning.
Third, GEDCOM facilitates data sharing among genealogists. Researchers often post GEDCOM files to collaborative sites, send them via email to cousins, or upload them to world tree systems. These shared files make it possible to merge family lines, verify connections, and discover new branches.
However, sharing GEDCOM also raises serious privacy and ethical questions, as the format can contain information about living individuals, sensitive dates, and potentially misused data points. Responsible usage therefore depends not only on technical understanding but on careful judgment and respect for the rights and safety of living people.
Origins in the LDS Church and FamilySearch
GEDCOM was developed by the Family History Department of The Church of Jesus Christ of Latter-day Saints (LDS Church), which operates FamilySearch, one of the world’s largest genealogical organizations. The LDS Church has long maintained extensive genealogical collections and systems, both for research purposes and as a service to the broader public.
As computerized genealogy emerged in the 1980s, the need to exchange data between different programs and mainframe systems became critical.
Around 1985, the LDS Church created the first versions of the GEDCOM specification to provide a uniform way for software to describe individuals, families, events, places, and sources in a portable format. The design reflected both practical constraints—limited computing resources, line-oriented storage devices—and conceptual goals such as representing lineage-linked family data consistently.
Over time, the specification evolved through multiple numbered versions, each refining the grammar and capabilities of the format. Because the format was offered freely, software developers across the genealogy ecosystem adopted it as the baseline for import and export features.
The long reign of GEDCOM 5.5 and 5.5.1
Among the many versions, GEDCOM 5.5, released in 1996, and its successor 5.5.1, drafted in 1999, became the most influential and widely implemented. Version 5.5 specified a line-oriented text format with ANSI or ANSEL character encodings, a maximum line length of 255 characters, and a variety of tags for individuals, families, events, places, notes, and sources.
It relied on continuation tags CONC and CONT for long values, and it formalized the hierarchy of records through level numbers and IDs.
GEDCOM 5.5.1 made modest updates, such as allowing UTF-8 encoding, adding support for email and web fields, and refining certain tags and structures. For many years, 5.5.1 lingered in a quasi-draft status: it was widely implemented by software vendors but not formally ratified by FamilySearch. Nonetheless, major platforms like Ancestry, MyHeritage, and various desktop programs typically exported GEDCOM files that were broadly compatible with 5.5.1 semantics.
In 2019, FamilySearch formally ratified GEDCOM 5.5.1, acknowledging its status as the industry’s exchange standard. Around the same time, another group released GEDCOM 5.5.5, a variant that builds on earlier versions and is presented as the current GEDCOM version in that particular specification lineage.
Regardless of these nuances, most genealogical programs in the marketplace continue to export files aligned with 5.5.1 semantics, meaning that genealogists routinely handle GEDCOM files that operate according to late-1990s design assumptions. This backward compatibility is both a strength—preserving decades of research—and a limitation when it comes to modern data needs such as rich media, complex relationships, and international character sets.
FamilySearch GEDCOM 7.0 and modern revisions
Recognizing the need for modernization, FamilySearch released FamilySearch GEDCOM 7.0 in 2021 as a significant update to the format. GEDCOM 7.0 mandates UTF-8 encoding, thereby eliminating the need to guess or negotiate complex legacy encodings like ANSEL or Windows-1252. It removes the line-length limit, simplifies long value handling by abolishing the CONC continuation construct, and introduces a cleaner extension mechanism.
One of the most important additions in GEDCOM 7.0 is GEDZIP, a formal container that bundles the .ged file together with associated media files into a single zip archive. Under 5.x versions, GEDCOM files typically stored only references (links or paths) to media such as photos or scanned documents; the actual files had to be managed separately and were often lost or mismatched over time.
GEDZIP addresses this long-standing complaint by standardizing a zip archive that includes one entry named gedcom.ged plus one entry per media file referenced. This arrangement, which uses the .gdz extension, makes it possible to transport both tree data and supporting documents in one container.
FamilySearch GEDCOM 7.0 also repositions the format as a more general-purpose hierarchical data representation language, comparable in spirit to XML, JSON, or YAML, but specialized for genealogical contexts. This modernization reflects the reality that genealogical data is increasingly exchanged via web APIs, cloud platforms, and diverse devices.
From the perspective of legacy platforms like MyHeirloom, the emergence of GEDCOM 7.0 and GEDZIP is promising. It points toward a future in which genealogical data, media files, and structured narratives can coexist within portable containers that can be ingested by different systems. MyHeirloom’s design philosophy aligns with this direction, encouraging users to organize genealogical facts within a Legacy Room that could, in the future, interface with standardized data exports.
To clarify the practical differences between common GEDCOM versions, it is helpful to summarize key features in a comparative table using the descriptions provided by specification sites.
GEDCOM 5.5
GEDCOM 5.5.1
GEDCOM 5.5.5
FamilySearch GEDCOM 7.0
This comparison illustrates why genealogists encounter subtle differences when importing or exporting GEDCOM between tools. A software package that assumes 5.5 semantics may misinterpret certain 5.5.1 tags or encodings, and vice versa. Similarly, GEDCOM 7.0’s GEDZIP containers require programs to support zip handling and new media payload structures. Understanding these distinctions helps researchers troubleshoot import issues.
Technical structure of GEDCOM files
Create a digital legacy that your children and grandchildren will be proud of.
Create a family legacyLine grammar: level, optional ID, tag, and value
At the heart of GEDCOM lies a simple but strict line grammar. Every line in a GEDCOM file contains a hierarchical level number, a tag, and an optional value; in many cases, there may also be an optional identifier enclosed in @ symbols. This consistent structure allows the entire file to be parsed line by line, with hierarchy inferred purely from the numeric levels.
In the traditional 5.5.1 description, a generic line takes the form: <level> [<optional @ID@>] <TAG> [<value>].
The level number indicates the depth of the current line in the logical hierarchy. Level 0 marks the beginning of a new top-level record, such as a header, individual, family, source, note, multimedia object, repository, submitter, or the trailer. Higher numbers—1, 2, 3, and so on—represent subordinate data connected to the line above.
The optional ID, fenced by @ symbols, provides a unique identifier for a record that can be referenced elsewhere in the file. Individual and family records typically carry such IDs at their level-0 lines, and other lines use pointers to reference them, creating a web of relationships across independent records.
The tag is a short code—often mnemonic—representing the type of information on the line: INDI for individual, FAM for family, BIRT for birth, DEAT for death, MARR for marriage, DATE for date, PLAC for place, NOTE for note, SOUR for source, and many more. Tags are defined in the specification and remain relatively stable across versions.
The value contains the content associated with the tag, such as a date string, a place name, a note text, or a pointer to another record. For instance, date values must adhere to the GEDCOM date format, which includes qualifiers like ABT (about), BEF (before), AFT (after), and range constructions like BET 1900 AND 1905.
Hierarchy and records: HEAD, INDI, FAM, SOUR, NOTE, OBJE, TRLR
A GEDCOM file is conceptually divided into three broad sections: a header, a collection of records, and a trailer. The header begins with the line 0 HEAD, marking the start of metadata about the file itself. Within the header, level-1 and level-2 lines may specify the GEDCOM version, the character encoding, the source program that generated the file, and other global information.
Following the header, the file consists of a series of records, each beginning with a level-0 line. The most common record types in lineage-linked GEDCOM are:
Each record includes subordinate lines that capture specific details. An INDI record might include events such as birth, death, christening, and occupation, along with name, sex, and references to family records. A FAM record might include marriage, divorce, and references to individuals via HUSB, WIFE, and CHIL lines for children.
The final section of the file is the trailer, indicated by the line 0 TRLR, which marks the end of the data stream. There are no blank lines or indentation in a standard 5.x GEDCOM file; the entire structure is defined by level numbers and tags.
The lineage-linked data model and family relationships
GEDCOM’s lineage-linked data model is based on the conceptual unit of the nuclear family. Rather than directly linking individuals to one another (for example stating that person A is the sibling of person B), GEDCOM links every relationship through the family record. An individual record points to a family as a child using the FAMC tag, and to one or more families as a spouse using FAMS.
This design has an important consequence: siblings are never explicitly declared as siblings but are instead inferred from shared parentage. If two individuals’ FAMC tags point to the same family record, they are siblings by implication. Similarly, extended relationships such as cousins, grandparents, or in-laws are inferred by traversing family links.
The lineage-linked model works reasonably well for many traditional family structures but reveals limitations in contemporary practice. Non-traditional arrangements—cohabiting partners without formal family units, multi-parent households, complex adoption scenarios, and chosen families—may be awkward to represent within strict FAM record semantics.
Platforms like MyHeirloom respond to these limitations by broadening the relational space. MyHeirloom’s Family Tree tool supports both genetic and non-genetic relationships, including marriage, adoption, step-family links, and unmarried partners, while My Tribe allows users to create profiles for important people beyond strict genealogical lines.
Dates, places, encodings, and other technical details
GEDCOM devotes particular attention to date representation, recognizing that genealogical research often involves uncertain, approximate, or conflicting dates. The standard date format uses day, three-letter English month, and year, for example 2 JUN 1985. Because research frequently relies on approximate dates, GEDCOM allows qualifiers such as ABT (about), BEF (before), AFT (after), EST (estimated), and CAL (calculated).
It also provides mechanisms for expressing ranges, periods, and dual years that reflect calendar changes or ambiguous sources. Partial dates—such as a year alone or a month and year—are fully valid within the specification.
Place values are typically recorded in a comma-separated format, moving from smallest to largest jurisdiction (for example, Springfield, Clark, Ohio, United States), though exact conventions vary by practice and local standards. GEDCOM does not enforce specific geoparsing rules but allows consistent textual descriptions that can later be geocoded by software.
Character encoding has historically been a thorny issue, with older files using ANSEL, ASCII, or Windows-1252, while modern versions require UTF-8. The declared encoding in the header is not always accurate, meaning robust readers must test the file and validate encoding assumptions.
In addition to these textual constraints, GEDCOM 5.x versions impose a maximum line length of 255 characters and require continuation tags for extending long values across multiple lines. GEDCOM 7.0, by contrast, removes the line-length limit and simplifies continuation semantics, reflecting modern text handling capabilities.
Practical use of GEDCOM in genealogical workflows
Exporting GEDCOM from common genealogy software and sites
Most major genealogy programs and websites support exporting tree data as GEDCOM, though the exact menu paths vary. In a typical desktop program, such as Family Tree Maker or Legacy, a user opens their main family file, selects an Export option under the File menu, and chooses GEDCOM as the output format.
They may be asked to specify the GEDCOM version, select which individuals or branches to include, and decide whether to compress media or restrict certain private facts.
On web platforms such as Ancestry, exporting a GEDCOM often involves navigating to tree settings and using an Export tree button. The site then generates a GEDCOM file based on the user’s tree data and offers it as a download, typically with the .ged extension. Users are advised to rename downloaded GEDCOM files in meaningful ways and move them from generic folders into organized genealogy directories.
MyHeritage similarly provides an Export to GEDCOM function, allowing users to include or exclude photos as part of the export process. Because traditional GEDCOM 5.x does not natively embed media, platforms may handle photos by bundling them separately or using proprietary extensions. GEDZIP under GEDCOM 7.0 offers a standardized alternative by packaging tree data and media together.
Importing GEDCOM into new tools and handling proprietary formats
Importing GEDCOM into a new tool typically involves creating a fresh tree file and using an Import GEDCOM option. For example, Family Tree Builder allows users to open the program, select Import GEDCOM from the File menu, choose the desired .ged file, and launch an import process that converts the data into the program’s proprietary format.
Legacy Family Tree provides an Import Wizard that scans drives for GEDCOM files, displays them, and prompts the user either to create a new file or to merge data. The program analyses the GEDCOM to ensure validity, reports any unsupported information, and optionally assigns a master source citation to all imported records.
In cases where genealogical information is stored in proprietary formats like .FTM, .PAF, or .FDB, users often need to export those files as GEDCOM before importing them into other tools. This process can be somewhat technical, but it underscores GEDCOM’s role as the intermediate bridge between otherwise incompatible systems.
At present, MyHeirloom’s Family Tree feature does not provide direct GEDCOM import or export, as the platform is currently oriented toward interactive, creative genealogy within its own interface. However, its future development roadmap includes GEDCOM import and export as planned capabilities, allowing you to eventually bring your existing data directly into its narrative environment.
Validating and understanding GEDCOM files
Before importing a GEDCOM file, genealogists are advised to validate its format and origin. A file truly in GEDCOM format typically ends with the .ged extension; if it instead ends with .zip, it may be a compressed archive containing a GEDCOM file that must first be unzipped. Some websites allow users to upload compressed GEDCOMs to save bandwidth, particularly when tree files approach sizes of dozens or hundreds of megabytes.
Opening a GEDCOM file in a text editor reveals what can look like a jumble of numbers, abbreviations, and data fragments—but this apparent chaos is just a structured outline. There are no blank lines and no indentation; level numbers and tags alone define the hierarchy. Records are organized in groups of lines, where each group represents a single individual or family.
Tools like GEDCOM validators, or even careful manual inspection, can detect common issues: missing trailer lines, inconsistent level numbering, invalid tag usage, or incorrect encoding declarations. Validating GEDCOM before import reduces the risk of partial or corrupted imports, where individuals appear without relationships or sources lose their links.
For genealogists who are not comfortable reading raw GEDCOM, privacy-preserving browser-based viewers have emerged to render .ged files without uploading them to remote servers. This illustrates how developers can build tools that respect both technical structure and contemporary privacy expectations.
Real-world example: merging an imported GEDCOM into a working tree
Consider a common scenario: an adult child has built a family tree in one online platform and receives a GEDCOM file from an older cousin who has been using a different program for decades. The child wants to merge the cousin’s data into their own tree while preserving accuracy and avoiding duplication.
The workflow begins by verifying that the cousin’s file truly is GEDCOM, then importing it into a separate, fresh tree file rather than directly into their main tree. Once imported, the child examines key individuals in the cousin’s tree, comparing names, dates, places, and sources with their own records.
Using the software’s merge tools, they then align individuals who represent the same person, merging facts and sources while retaining their own preferred version of disputed data. After the merge, the child might export a combined GEDCOM as a backup, ensuring that the newly enriched tree is preserved in a portable format.
GEDCOM, online genealogy platforms, and digital legacy ecosystems
Uploading GEDCOM to collaborative websites
Beyond personal software, many collaborative genealogy websites invite users to upload GEDCOM files to populate large shared trees. When a website says upload your GEDCOM, it usually means that the entire file is sent from the user’s browser to the site’s server. The site’s code then reads the file, stores at least a copy of the contents, and builds visible tree structures.
This server-side architecture is standard on the web, but it has serious implications for privacy and data control. Once a GEDCOM is on someone else’s computer, it becomes subject to that organization’s retention policies, security practices, and potential data breaches.
Some platforms strip or mask information on living persons as a matter of policy, removing individuals born after a certain year or replacing details with private labels. These measures reflect broader awareness of privacy concerns but do not eliminate the need for user judgment. Uploading GEDCOM to public sites remains a double-edged sword that can disseminate sensitive information.
MyHeirloom takes a different approach by defaulting accounts to private and allowing users to selectively make specific Keepsakes, recipes, or Family Tree sections public. Rather than encouraging wholesale upload of full GEDCOM files to public databases, MyHeirloom emphasizes curated sharing, keeping the bulk of your Legacy Room accessible only to you, invited family members, or designated Trustees.
Client-side GEDCOM viewing and privacy-preserving tools
In response to concerns about server-side GEDCOM handling, some developers have created tools that process GEDCOM entirely within the user’s browser, without uploading it anywhere. These tools run parsing and rendering code entirely on the user’s machine, ensuring that no request carrying the user’s GEDCOM, photos, or place names is sent to any remote endpoint.
This client-side approach does not solve every privacy problem, but it demonstrates a viable model for privacy-preserving interpretation of genealogical data. As awareness of data protection grows, more tools may adopt similar architectures, enabling genealogists to work with GEDCOM files in richer ways without surrendering control.
For a platform like MyHeirloom, security and data control are central. MyHeirloom operates under a strict privacy-first architecture, ensuring that personal memories and legacy records are never sold or shared with third-party advertisers. When future GEDCOM import features are introduced, they will be designed to align with this privacy philosophy.
GEDCOM and multi-dimensional legacy platforms like MyHeirloom
While GEDCOM is optimally suited for representing structured genealogical facts, it does not attempt to capture the full richness of personal legacy. Memories, emotions, recipes, audio recordings, letters, health narratives, and instructions for future generations all lie outside GEDCOM’s historical remit. As a result, many researchers find themselves juggling multiple systems.
MyHeirloom addresses this fragmentation by providing a Legacy Room where various dimensions of a person’s life can be organized together. Within this private space, users can create Keepsakes, build a Family Tree that includes both genetic and non-genetic relationships, use My Tribe to represent important friends, preserve recipes in a Family Cookbook, and secure sensitive documents in DocuVault.
Please note: While DocuVault provides a highly secure, private space to organize copies of wills, deeds, health records, and personal instructions, MyHeirloom is not a legal service, financial advisor, or medical resource, and does not replace official estate planning, a legally binding will, or professional legal advice. It does not guarantee absolute security or permanent preservation, but uses robust industry-standard encryption to protect your records.
In this ecosystem, GEDCOM plays a complementary role, providing the structured genealogical backbone that situates stories in an ancestral context. A tree imported or manually recreated from GEDCOM can anchor Keepsakes in specific lineage positions, while MyHeirloom’s Life Timeline and multimedia features bring those facts to life.
By unifying genealogical facts with narrative and sensitive information under user-controlled privacy settings, MyHeirloom extends GEDCOM’s utility from pure data exchange to holistic legacy preservation. Users can start for free to experiment with this integrated approach, allowing families to gradually weave their existing research into a more meaningful digital inheritance.
Privacy, ethics, and security in sharing GEDCOM files
The ethical stakes of genealogical data about living individuals
Genealogists often focus on records of deceased persons, but much of the information they collect pertains to living people: birth dates, marriage details, addresses, occupations, and family relationships. When this information is entered into genealogical databases and exported as GEDCOM files, sharing such files online can implicate privacy rights and ethical obligations.
One significant risk is the inadvertent exposure of sensitive identifiers that could end up embedded in GEDCOM files posted on public websites. Because bad actors may attempt to use genealogical databases to mine security question answers or trace familial connections for fraud, genealogists have a responsibility to consider how much living-person data they disseminate.
Ethically, genealogists must also respect the preferences and boundaries of their relatives. Not everyone wants their personal information shared with distant cousins or strangers. Laws in some jurisdictions restrict sharing personal information about living persons without their explicit consent, making it crucial to treat living individuals as active stakeholders in family narratives.
Once a GEDCOM file is shared—whether uploaded to a database or emailed to a cousin—the originator loses control over its further dissemination. The recipient may pass it on, post it publicly, or merge it into other public trees, making a minimal disclosure mindset essential.
Common privacy protections and site policies
In response to privacy concerns, some GEDCOM-based websites enforce policies that limit exposure of living individuals. One approach is to strip out all persons born after a certain year when a file is uploaded, based on standard privacy laws. Another approach is to retain names but hide detailed information, replacing dates and places with private labels.
However, these site policies should not be relied upon as the sole protective mechanism, as they may misclassify individuals or vary in implementation quality. Responsible genealogists should proactively clean their GEDCOM files before sharing, removing or obscuring sensitive data about living individuals.
Give them the home they deserve. Bring your family legacy into the digital age.
Start archivingWhile there are typically easier ways for criminals to obtain information than trawling genealogical databases, the existence of risk does not absolve genealogists of attention to privacy. Good genealogical citizenship involves thinking not only about historical accuracy but also about contemporary ethical obligations and the potential consequences of data exposure.
Best practices for safe GEDCOM sharing
Several practical guidelines emerge from ethical discussions around GEDCOM. First, genealogists should consider excluding data about living individuals from GEDCOM files they intend to share publicly, focusing instead on people who have been deceased for at least a decade or longer.
Second, even when sharing with relatives via email or private channels, genealogists can adopt a minimal disclosure mindset. Include only the information necessary for genealogical collaboration, avoid unnecessary detail about addresses or financial matters, and refrain from embedding high-value identifiers.
Third, genealogists should double-check whether their source information is properly included in GEDCOM exports before sharing, so that recipients can evaluate the reliability of data. Conversely, when receiving GEDCOM files from others, genealogists should critically assess source coverage and avoid uncritical import.
In parallel, platforms like MyHeirloom support privacy-respecting legacy work by allowing users to control exactly who sees their content. Users can store sensitive documents in DocuVault under an additional password, choose whether Trustees gain access after their passing, and avoid storing high-risk information such as passwords or credit card numbers.
Common questions about privacy and GEDCOM
Is a cloud folder or ordinary backup enough to protect my genealogical data?
A cloud folder or simple backup can preserve files, but it does not inherently protect privacy or provide structured control over who sees which information. GEDCOM files stored in generic folders may be accessed by anyone with device access, and sharing them intact can expose data about living individuals. Privacy-focused platforms like MyHeirloom add layers of control, allowing selective visibility and secure compartments such as DocuVault, which go beyond raw file storage.
What is the difference between storing files and preserving a legacy?
Storing files is about preservation of data; preserving a legacy is about organizing that data into meaningful narratives, relationships, and instructions for future generations. GEDCOM excels at storing structured genealogical facts, but it does not capture the emotional context, stories, and sensitive guidance that families often want to pass on. Combining GEDCOM with platforms like MyHeirloom, which support Keepsakes, Family Tree, My Tribe, and DocuVault, enables both factual and contextual preservation.
How can I share genealogical information without violating relatives’ privacy?
You can do so by cleaning GEDCOM files before sharing, focusing on people long deceased or masking details about living individuals, and by using platforms that allow selective sharing of particular stories or branches. MyHeirloom can help by letting you publish specific Keepsakes or recipes while keeping the broader Legacy Room private, enabling collaboration without exposing all personal data.
Limitations of GEDCOM and emerging alternatives
Structural and conceptual limitations
Despite its longevity and utility, GEDCOM has notable limitations. Its lineage-linked model, oriented toward nuclear families and binary parental roles, struggles to represent complex modern relationships. It does not natively capture nuanced gender identities, multi-parent arrangements, or non-familial relationships that matter in social and emotional terms.
GEDCOM’s textual nature also leads to variability in practice, with place names, occupations, and notes often recorded with inconsistent formats. The absence of strict schemas for certain fields means that messy data is common, particularly in large trees compiled over decades by multiple contributors.
Another limitation is GEDCOM’s historical focus on records rather than narratives. Though it allows notes and source citations, it does not provide rich constructs for stories, reflections, or multimedia context. Memories captured in GEDCOM tend to be subordinate textual notes attached to events or individuals, rather than standalone narrative artifacts.
GEDCOM X: a more modern conceptual model
To address some of these limitations, FamilySearch introduced GEDCOM X, a related but distinct specification set that defines a more modern conceptual model for genealogical data. GEDCOM X consists of several core specifications, including a date format specialized for genealogical dates, a conceptual model describing data types such as persons, relationships, and sources, and serialization formats in XML and JSON.
The GEDCOM X conceptual model explicitly defines entities such as persons and relationships, moving beyond GEDCOM’s nuclear-family records to a more flexible representation of connections. Its XML and JSON serializations align with contemporary web technologies, making it easier to build web services, APIs, and interoperable applications.
While GEDCOM X does not replace traditional GEDCOM in the marketplace, it illustrates a direction for future genealogical standards. For MyHeirloom, which already uses web-friendly formats and bundles diverse media with structured content inside Legacy Rooms, GEDCOM X concepts align with its design philosophy even though the platform currently focuses on its own models.
FamilySearch GEDCOM 7.0 and GEDZIP as practical improvements
As discussed earlier, FamilySearch GEDCOM 7.0 modernizes core aspects of the specification while still retaining the familiar line-oriented grammar. By mandating UTF-8 encoding, eliminating line-length limits, simplifying continuation mechanics, and providing a standardized extension mechanism, 7.0 reduces ambiguity and improves interoperability.
Its introduction of GEDZIP directly addresses one of traditional GEDCOM’s most pressing limitations: the lack of integrally bundled media. In a GEDZIP archive, the .gdz file is an ordinary zip container. It contains one entry named gedcom.ged and one entry for each local media file referenced in the GEDCOM data stream.
While adoption of GEDCOM 7.0 and GEDZIP is still evolving, they represent concrete steps toward bridging genealogical records with richer digital archives. Platforms like MyHeirloom, which already provide integrated storage for photos, audio, video, and documents within Keepsakes and DocuVault, can conceptually align with GEDZIP by ensuring that future import/export mechanisms map media references into the platform’s own media structures.
The role of platform-specific solutions alongside standards
Given GEDCOM’s limitations and the complexity of modern digital life, it is unrealistic to expect a single standard to fully capture every dimension of personal legacy. Instead, the ecosystem consists of a mix of standards and platform-specific solutions. The practical goal is to ensure that core genealogical facts remain portable and that richer narrative content can coexist with standardized data.
MyHeirloom exemplifies this multi-layered approach, supporting features like Life Timeline, My Tribe, Family Tree visualization, Family Cookbook, and DocuVault. At the same time, MyHeirloom is conceptually prepared to interface with GEDCOM by mapping individuals, relationships, and events onto its Family Tree structures, while linking those entities with Keepsakes and documents.
From a research standpoint, this suggests a pragmatic strategy: use GEDCOM as the stable backbone for genealogical facts and adopt platforms like MyHeirloom to handle narrative, multimedia, and sensitive information. This approach respects the roles and limits of each system while maximizing the resilience and meaning of the overall digital legacy.
Integrating GEDCOM with personal legacy work on MyHeirloom
Moving from tree-centric research to holistic legacy preservation
Many family historians begin their journey with a strong focus on constructing a family tree: identifying ancestors, tracing lines, sourcing dates and places, and verifying relationships. GEDCOM supports this tree-centric paradigm effectively by providing structured storage for individuals, families, events, and sources. Yet as genealogists deepen their work, they often realize that the tree alone does not capture the richness of their family’s story.
The shift from pure genealogy to holistic legacy preservation involves connecting these diverse materials in coherent ways. Someone researching their grandmother’s migration might want not only to record the departure date and ship name, but also to preserve oral histories, photos, documents, and reflections on how that move shaped their family’s identity.
MyHeirloom’s Legacy Room provides a structured environment where tree data and richer legacy materials can coexist. Users can create a Family Tree that captures genealogical relationships and then anchor Keepsakes to specific individuals or events, using photos, audio, video, and text to narrate experiences. A Life Timeline can visualize major moments across a person’s life, while My Tribe ensures that non-genealogical connections are included in the narrative.
Practical strategies for using GEDCOM alongside MyHeirloom today
Even before direct GEDCOM import is implemented, genealogists can use GEDCOM files in conjunction with MyHeirloom. A practical strategy begins by exporting a GEDCOM file from existing tree software, ensuring it includes source citations and excludes sensitive information about living individuals.
The genealogist can then open the GEDCOM in a viewer to examine its structure, identifying core family lines or individuals they want to feature. Next, they log into MyHeirloom and start for free by creating a Legacy Room. Inside the Family Tree feature, they manually add principal ancestors, using information from the GEDCOM file to populate key details.
As they add individuals to the Family Tree, they simultaneously create Keepsakes for major life events or stories. For a great-grandparent whose GEDCOM record shows a 1920 marriage, they might create a Keepsake describing the wedding, including photos, scanned invitations, or oral history transcripts. Weaver, MyHeirloom’s AI-based guide, can help them recall and enrich details, asking questions about the setting and significance of the event.
Continuing this process over time, the genealogist gradually weaves their GEDCOM-derived facts into MyHeirloom’s broader legacy structures. DocuVault can store digital copies of key records referenced in the GEDCOM, while Family Cookbook preserves recipes associated with particular ancestors, transforming scattered tree data into a coherent inheritance.
Trusteeship, continuity, and the long-term fate of GEDCOM data
A frequent concern among genealogists is what will happen to their research after they die. GEDCOM files on personal computers, cloud drives, or old software installations may be inaccessible to descendants who lack the technical knowledge to interpret them. Even if the files survive, without guidance they may be overlooked or misunderstood.
MyHeirloom addresses this continuity challenge through Trusteeship, letting users invite trusted individuals to take custody of the account after their passing. Trustees gain view-only access to all content in the Legacy Room, can administer a Guest Book, and may be allowed to edit the Family Tree or change subscription terms depending on permissions, while being prevented from erasing the account.
While GEDCOM itself has no concept of trusteeship, pairing GEDCOM-derived genealogical data with a platform that supports posthumous continuity ensures that the factual backbone of a family tree remains accessible. Organizing your research inside MyHeirloom ensures that Trustees will have a clear, structured, and secure environment in which to explore and share that legacy.
Methodological recommendations for working with GEDCOM
Data quality, source integrity, and misinformation
As collaborative genealogical databases have grown, so too has the problem of misinformation. Many GEDCOM files circulating online contain unsourced guesses, conflated individuals, misattributed relationships, and speculative dates. When these files are uploaded to large public trees, errors can propagate widely, creating persistent myths.
To mitigate this, genealogists should treat GEDCOM as a technical representation of research decisions, not as an unquestionable truth. Before importing GEDCOM data from others, they should evaluate source coverage, check key facts against independent records, and document any alternative hypotheses.
When exporting their own GEDCOM files, genealogists should aim to include source citations so that recipients can see the evidentiary basis for each fact. Within MyHeirloom, users can further enrich source information by attaching digital copies of records in DocuVault and referencing them within Keepsakes, clarifying what evidence supports particular stories.
Naming conventions, file management, and version control
Good file hygiene is essential for long-term GEDCOM management. Genealogists should adopt clear naming conventions for their GEDCOM exports, incorporating surnames, date stamps, and perhaps version identifiers so that files can be distinguished and tracked over time. Storing files in organized directories separate from temporary downloads is also crucial.
Version control is particularly important when GEDCOM files are used to move data between systems. A genealogist might keep a baseline GEDCOM snapshot before major updates, then export a new version after substantial changes. If problems arise during an import, they can easily revert to the earlier snapshot.
MyHeirloom can serve as part of this version control strategy. Because the Legacy Room is a living environment where changes are reflected dynamically, users can rely on MyHeirloom to maintain a current representation of their work, while using GEDCOM exports from other tools as point-in-time reference files.
Integrating genealogy with broader personal archiving
Methodologically, the most robust digital legacies integrate genealogical research with broader personal archiving practices. This means not only preserving GEDCOM files but also organizing photos, letters, journals, recipes, audio recordings, and documents in accessible, meaningful ways.
Practically, genealogists can adopt a workflow in which each major genealogical discovery is matched with narrative and media documentation. When a new ancestor is identified, the genealogist might create a MyHeirloom Keepsake describing the research process, interpreting what the discovery means, and attaching digital images of the record.
By combining GEDCOM’s structured genealogical backbone with MyHeirloom’s narrative and security features, genealogists and families can create digital legacies that remain useful, trustworthy, and emotionally resonant. The emphasis shifts from merely storing data to crafting an inheritance of meaning.
Conclusion: GEDCOM's ongoing role in genealogy and digital legacy
GEDCOM began in the mid-1980s as a pragmatic solution to a technical problem: how to exchange genealogical data between diverse, incompatible computer systems. Over decades, it has grown into the de facto standard for representing lineage-linked facts—names, dates, places, relationships, and sources—across the global genealogy ecosystem.
At the same time, GEDCOM’s limitations have become apparent in the face of modern digital life, as it struggles with complex social structures and offers limited constructs for rich narrative context. No single standard can encompass the full breadth of personal legacy, and standardizing narrative or emotional context remains a challenge.
In practice, the most effective strategy is to recognize GEDCOM’s strengths and use them wisely. It remains invaluable for moving genealogical facts between tools, backing up tree data, and collaborating with other researchers. Yet it should be complemented by platforms and practices that handle narrative, multimedia, sensitive documents, and privacy in more nuanced ways.
MyHeirloom exemplifes such a platform, offering a Legacy Room that brings together Family Tree, My Tribe, Keepsakes, Life Timeline, Family Cookbook, and DocuVault. By combining GEDCOM’s technical backbone with privacy-first, narrative-rich environments like MyHeirloom, we can ensure that our genealogical research becomes part of a living, enduring legacy that future generations can understand, trust, and cherish.
FAQ
1. What exactly is a GEDCOM file?
A GEDCOM file is a structured plain-text file, usually with the .ged extension, that encodes genealogical data such as individuals, families, events, relationships, notes, and sources using a standardized line grammar. Developed by the LDS Church and FamilySearch, it has become the de facto standard for transferring family tree information between different genealogy programs.
2. How do I open and use a GEDCOM file from another person or website?
To use a GEDCOM file, first ensure it truly is a .ged file and unzip it if it arrives compressed. Open your genealogy software, use its Import GEDCOM function, and create a new tree from the file so you can inspect the data. Review the individuals, families, and sources to resolve duplicates before merging selected information into your main tree.
3. Are GEDCOM files safe to share online from a privacy perspective?
GEDCOM files often contain detailed information about living individuals, which can pose privacy risks if shared publicly. Best practice is to clean GEDCOM files before sharing, focus on deceased persons, and remove or mask sensitive details. Using platforms like MyHeirloom supports selective, privacy-controlled sharing of specific stories or branches rather than entire databases.
4. What is the difference between GEDCOM 5.5.1 and FamilySearch GEDCOM 7.0?
GEDCOM 5.5.1 is a widely implemented older specification that allows UTF-8 encoding but retains a 255-character line limit and uses continuation tags for long values. FamilySearch GEDCOM 7.0 is a modern version that mandates UTF-8, removes line-length limits, simplifies continuation semantics, and introduces GEDZIP archives to bundle media files directly with tree data.
5. How does MyHeirloom fit into work I already have in GEDCOM format?
MyHeirloom complements GEDCOM by providing a Legacy Room where genealogical facts can be integrated with stories, photos, audio, video, recipes, and secure documents. While direct GEDCOM import is planned for future release, users can start for free to recreate key branches of their tree manually, then enrich those branches with narrative and archival content.
6. Is GEDCOM enough to preserve my family history for future generations?
GEDCOM is excellent for preserving structured genealogical data like names, dates, and relationships in a portable format. However, it does not preserve the narrative richness of family history, such as memories, stories, recipes, or audio recordings. Combining GEDCOM with a platform like MyHeirloom ensures that both factual data and emotional context are passed down in a coherent, accessible form.
MyHeirloom gives you a dedicated Legacy Room—a private, secure space to collect photos, videos, documents, and stories.
Start now for free