GEDCOM 5.5.1 vs 7.0: What Changed and When to Convert
For about twenty years, one version of GEDCOM ran family history: 5.5.1. Then, in 2021, GEDCOM 7.0 arrived. It was the first new version in more than two decades. If you export a file today, you may be asked which version you want. If you receive a file, you may need to know which version it is before your program will touch it.
This guide sets the two versions side by side. It explains what changed, what stayed the same, and when a conversion helps or hurts. If the words are new to you, what is a GEDCOM file is the place to start. When you are ready to convert a file, the GedConvert tool on the home page handles 5.5.1 to 7.0 and 7.0 to 5.5.1 on paid plans.
A Short History of the Two Versions
GEDCOM grew up in steps through the 1980s and 1990s. Version 5.5 came out in 1996. Version 5.5.1 came out in 1999 as a draft. That draft was never made fully final in its day, but every program adopted it anyway. For two decades it was the version in real use, draft status and all. It was published in final form later so the record matched the practice.
Work on a true next version took years. The result, GEDCOM 7.0, was released in 2021 by FamilySearch. It did not try to reinvent the format. It kept the same line-based shape — levels, tags, values — and the same core records. What it did was tighten the rules, drop old baggage, and add a small set of new tools. Later updates in the 7.0 line, such as 7.0.x patch releases, clarified wording without changing the shape.
That history explains the present mix. Most files in the wild are 5.5.1, because most programs still export it by default. New tools are adding 7.0 export and import year by year. You will live with both versions for a long time, which is why knowing the gap matters.
How to Tell Which Version a File Is
Look at the header. Every file states its version in two lines:
| Line | 5.5.1 file | 7.0 file |
|---|---|---|
| Version line | 2 VERS 5.5.1 | 2 VERS 7.0 |
| Form line | 1 GEDC | 1 GEDC |
| Encoding line | 1 CHAR UTF-8 (or ANSEL) | 1 SCHMA or no CHAR line |
The simplest test is the VERS line. In a 7.0 file, the GEDC structure works a little differently and the file must be UTF-8, so there is no CHAR ANSEL choice to make. A text editor and a search for "VERS" tell you the version in seconds. A validation report also states it at the top, along with the program that wrote the file.
File names do not tell you the version. Both versions use the .ged name. Never guess from the name or the date. Read the header.
The Changes That Matter Most
One Encoding: UTF-8 Only
This is the biggest practical change. Version 5.5.1 allows several encodings: ANSEL, ASCII, UTF-8, and UTF-16 among them. Each file states its choice in the CHAR line, and files often state it wrong. The result is the garbled names problem covered in GEDCOM encoding errors explained.
Version 7.0 ends the choice. Every 7.0 file is UTF-8. One rule, no CHAR line needed, no mismatch possible. Names with accents and letters from any alphabet travel in one known form. If your tree holds names from many countries, this change alone is a strong reason to prefer 7.0 when your tools support it.
No Line Length Limit
In 5.5.1, a line holds at most 255 characters. Long notes and long values must be split with CONC and CONT tags, and exports often split them badly. In 7.0, the limit is gone. A line can be as long as the value needs. Files get simpler, and one whole class of faults — bad splits that add stray spaces or breaks — goes away.
The flip side matters for conversion down. A 7.0 file with long lines must have those lines split per the 5.5.1 rules when it is converted back. A good converter does this for you. A careless one writes long lines into a 5.5.1 file and hands the next program a new set of errors.
A Tighter Date Grammar
Both versions write dates in the same core form: day, month code, year, with words like BEF, AFT, ABT, and BET for ranges and estimates. Version 7.0 tightens the edges. It clarifies how calendars are marked, how month codes work for the French Republican and Hebrew calendars, and which forms are legal in a date period. It also allows a time part on some dates in a strict form.
For most trees, real dates convert cleanly both ways. The dates at risk are the loose ones: free-text dates that 5.5.1 programs let slide. Under 7.0 rules they stand out as errors. That is strict, but it is also honest — a date no program can parse is a date no program can sort or check. The full date story is in GEDCOM dates explained.
Notes and Shared Notes
In 5.5.1, a note can be inline text or a link to a NOTE record. In 7.0, shared notes get their own record type, SNOTE, with clearer rules for where notes may appear. The change sounds small. It pays off when the same note — a family story, a shared research warning — is tied to many records. In 7.0 that note is one record with a stable identity, not scattered copies.
Conversion note: when a 7.0 file with shared notes moves down to 5.5.1, the notes are written in the 5.5.1 note forms. The text survives. The clean shared structure may become linked NOTE records or inline text, based on the converter.
Media Links Get Stronger
Both versions link to media files rather than holding them. Version 7.0 sharpens the rules for those links: file paths and web links are stated in a clearer form, and the title and type of a media item are easier to carry. Photos still do not travel inside the file in either version. You must still move the media files with the .ged file.
Extensions Are Declared
Programs have always added custom tags with a leading underscore. Version 7.0 asks programs to declare those extensions in the header, in a SCHMA structure that names the extension and where its rules can be found. Old files keep their custom tags a mystery. New files can state what their extra tags mean, so the next program has a chance to keep the data instead of dropping it in silence.
What Did Not Change
The core of your tree is safe in both versions. Person records, family records, names, the main events, places, and sources work the same way. IDs and the links between records work the same way. If your file is a clean 5.5.1 file with UTF-8 text and legal dates, a conversion to 7.0 changes the wrapper far more than the content. Most people in most trees will never see a difference in their facts.
| Feature | GEDCOM 5.5.1 | GEDCOM 7.0 |
|---|---|---|
| Status | Draft from 1999, in wide use for two decades | Released 2021, current version |
| Encoding | ANSEL, ASCII, UTF-8, UTF-16 and more | UTF-8 only |
| Line length | 255 characters at most, split with CONC / CONT | No limit |
| Shared notes | NOTE records and inline text | SNOTE records with clearer rules |
| Extensions | Custom tags, undeclared | Custom tags, declared in SCHMA |
| Date grammar | Core forms plus loose practice | Same core forms, tighter rules |
| Who reads it today | Almost every program and site | A growing list of programs and sites |
When to Convert — and When to Wait
Convert up to 7.0 when your main program reads and writes 7.0 well, when your tree holds many names that ANSEL or mixed encodings keep breaking, or when a service or collaborator asks for a 7.0 file. Also convert when you archive a tree for the long term: one encoding and no line limit make 7.0 the safer bet for a file that must open in twenty years.
Wait when your main program only handles 5.5.1, or handles 7.0 in part. A conversion you cannot import helps no one. Also wait when you share files with family who use old tools. Send them the version their tool reads, not the newest version on paper.
Convert down to 5.5.1 when a file was made as 7.0 but the program or site you need accepts only 5.5.1. That path is common today. Expect the text to stay UTF-8, long lines to be split, and any 7.0-only structures to be written in their closest 5.5.1 form. After a down-conversion, validate the result. The article on why GEDCOM exports fail validation shows how to read the report.
One rule covers both ways: keep the original file. Conversion writes a new file. It never edits the one you gave it. Store the original beside the converted copy, with the version in your own file name if that helps, like tree-551.ged and tree-70.ged.
How Conversion Works on GedConvert
Version conversion is a paid feature. You upload the file, pick the target version, and get a new file plus a report of what changed. Changes are format changes: encoding set to UTF-8, lines split or joined per the target rules, header rebuilt, notes and extensions written in the target form. Facts are not changed. If a value has no clean home in the target version, the report says so, line by line, instead of hiding the loss. Plans, including batch conversion and API access, are on the pricing page. The free plan covers the validation report and the individual and family CSV tables for either version, so you can inspect a file before you pay to convert it.
Frequently Asked Questions
Is GEDCOM 7.0 better than 5.5.1? As a spec, yes: it is clearer, stricter, and drops the encoding mess. As a choice today, it depends on your tools. The best version is the newest one that every program in your chain reads well.
Will 5.5.1 files stop working? No. Programs keep reading them because almost every existing file uses that version. Support will last for many years. There is no deadline by which you must convert.
Does converting change my family facts? A careful conversion does not change names, dates, places, or links. It changes the form those facts are stored in. Always validate after conversion and spot-check a few people against the original.
Can a 7.0 file hold things a 5.5.1 file cannot? A few structures are new or cleaner in 7.0, such as shared notes as SNOTE records and declared extensions. When such a file is converted down, those parts are written in the nearest 5.5.1 form and listed in the conversion report.
My program says it exports GEDCOM but names no version. What do I get? Most likely 5.5.1, still the default in most tools. Export a small test file and read the VERS line in the header to be sure.
Should my backup copy be 7.0? If your tools support it, a 7.0 backup is a good long-term copy. Keep the file your main program exports natively as well, so you hold both forms. The backup guide covers the full routine.
References
- https://gedcom.io/ — The home of the GEDCOM standard, with the full 7.0 spec and the 5.5.1 spec for comparison.
- https://www.archives.gov/research/genealogy — The U.S. National Archives guide to genealogy research and records.
- https://www.loc.gov/ — The Library of Congress, a major source of census, local history, and family history material.