GEDCOM Encoding Errors: ANSEL, UTF-8 and the Garbled Names Problem

A name comes out wrong. José becomes José. Müller becomes M?ller. A Polish town loses half its letters and gains a row of boxes. The rest of the file looks fine, which makes it stranger. Dates are right. Places in plain English are right. Only the names with special letters are hurt.

This is an encoding error. It is one of the most common faults in family history files, and one of the best understood. The data is almost never lost. It was written with one character map and read with another. Fix the map, and the names come back. This guide explains how text encoding works in GEDCOM, what ANSEL is, why UTF-8 won, and how to fix a garbled file. When you want a file checked and repaired, the GedConvert tool on the home page reads the real bytes of your file and reports what it finds.

What Encoding Means, in Plain Words

Computers store text as numbers. An encoding is the map between numbers and letters. The letter A might be number 65. An accented letter, like é, is a different number. If the writer and the reader use the same map, the text is perfect. If they use different maps, each number turns into the wrong letter on the far end.

Plain English text hides the problem. The basic letters, A to Z, digits, and common marks sit at the same numbers in almost every map. That is why a garbled file still shows most names just fine. The letters that differ between maps are the special ones: accents, umlauts, the letters of other alphabets, and marks like the curly quote. Those letters are common in family history, since our ancestors did not all spell their names in plain English.

So an encoding error has a clear shape. If the damage hits only special letters, and the plain text is clean, you are looking at a map mismatch — not at lost data and not at a broken file.

The Maps You Will Meet in GEDCOM Files

Each 5.5.1 file states its map in the header, on the CHAR line: 1 CHAR ANSEL, or 1 CHAR UTF-8. The reader trusts that line. Most encoding disasters start when the line lies — the file states one map while its bytes follow another.

ANSEL: The Genealogy Character Set

ANSEL deserves its own section because GEDCOM made it famous. ANSEL stands for American National Standard for Extended Latin. It was built for library work, to hold the accented letters used in catalogs for many languages. The GEDCOM spec adopted it, and for years it was the default way to store names with accents in a GEDCOM file.

ANSEL has one trick that breaks modern readers. In ANSEL, many accented letters are stored as two parts: the accent first, then the base letter. The é in José is not one unit. It is an acute accent code followed by the letter e. The reader must combine them. This is called a combining form, and ANSEL puts the mark before the letter, where Unicode puts it after — if Unicode uses two parts at all, since Unicode also offers é as a single code.

That design was fine when every reader knew ANSEL. It fails now. UTF-8 readers do not know ANSEL bytes. An ANSEL file read as UTF-8 shows stray marks, missing letters, or the famous pattern where one letter becomes two odd ones. And ANSEL cannot hold alphabets like Greek, Cyrillic, Hebrew, or Chinese at all. A family tree that spans those alphabets cannot live in ANSEL, no matter how carefully it is written.

UTF-8: The One Map for Everything

UTF-8 is the encoding of the modern web. It holds every letter of every alphabet, plus symbols and emoji, in one map. A letter takes one to four bytes. The plain English letters take one byte each and match ASCII exactly, which is why old and new text mix so well in UTF-8 files.

GEDCOM 7.0 made UTF-8 the only allowed encoding. That single rule ends most of this guide's problem class for new files. There is no CHAR line to get wrong, because there is no choice to state. The version story is told in full in GEDCOM 5.5.1 vs 7.0. For 5.5.1 files, UTF-8 is one choice among several, and still the best one: every modern program reads it, and it holds all the names your tree will ever meet.

The Classic Failures, One by One

ANSEL read as UTF-8. The file states UTF-8 or states nothing, but its bytes are ANSEL. Accents detach from their letters or turn into odd marks. Names from French, German, and Scandinavian lines suffer most. Fix: read the file as ANSEL, then save it as UTF-8.

UTF-8 read as Windows-1252. The file is fine UTF-8, but a program or an editor opens it with a Western European map. Each multi-byte letter becomes two wrong letters. José becomes José — the é pair is the fingerprint of this fault. Fix: open with UTF-8 chosen by hand, or convert the file so the reader cannot guess wrong. A byte order mark at the start of the file helps Windows tools choose UTF-8.

Double encoding. The worst case, and still fixable in most files. A UTF-8 file was read as Windows-1252, which turned é into é, and then saved as UTF-8 again. Now é is stored as real UTF-8 text. The file states UTF-8 and truly is UTF-8 — of the wrong letters. Fix: reverse the bad step. Read the text as if it were Windows-1252 bytes and decode those bytes as UTF-8. Tools that repair encoding know this pattern. If a file went through the bad save twice, the damage doubles and the repair must run twice too.

UTF-16 surprises. A program exports UTF-16, where each letter takes two bytes. A text editor shows the file with spaces between letters or refuses it. Some imports read only the first half of each pair and produce nonsense. Fix: convert the file to UTF-8. The text itself is sound Unicode; only the storage form is awkward.

The header lies. The CHAR line says ANSEL. The bytes are UTF-8. Or the reverse. Every reader that trusts the header reads the file wrong, all at once. This is why a validator reads the bytes, not just the header. Fix: make the header tell the truth, or better, convert the file to UTF-8 and set the header to match.

How to Fix a Garbled File

Work in this order, and keep the original file untouched until you hold a clean copy:

1. Confirm the fault is encoding. Damage only on special letters, plain text clean. If whole lines are missing or the file will not open at all, the problem is different — start with how to open a GEDCOM file.
2. Read the header. Note the CHAR line. That is the claim. Your job is to test the claim against the bytes.
3. Try the likely maps. Open the file in an editor that lets you pick the encoding. Try UTF-8, then ANSEL if your editor offers it, then Windows-1252. The right map makes every name snap into place at once. The wrong maps leave the damage in place.
4. Convert to UTF-8. Once the file reads clean, save it as UTF-8 and make sure the CHAR line says UTF-8. For a 7.0 file, no CHAR line is needed.
5. Validate the result. Run the fixed file through validation to catch any other faults the garbling hid. The full fault list is in why GEDCOM exports fail validation.
6. Spot-check in your program. Import into a new, empty tree and check three names with special letters — one French or Spanish, one German or Scandinavian, one from any other alphabet in your tree.

On GedConvert, the repair on paid plans covers this exact fix: detect the real encoding from the bytes, convert to UTF-8, correct the header, and list what changed. The repair fixes format only. It never changes the letters of a name — it makes the file state them in a map every reader shares. Plans are on the pricing page, and the free plan's validation report will tell you whether encoding is your file's problem before you pay for anything.

How to Stop It Happening Again

Export as UTF-8 whenever your program offers the choice. It is the one map that holds every name and that every modern tool reads. Avoid opening GEDCOM files in word processors, which love to re-save text in their own default map. If you must view a file in an editor, do not save it from the editor unless you are sure the save keeps UTF-8.

When you send a file to family, say which encoding it uses if you know, and prefer UTF-8. When you receive a file with garbled names, do not "fix" the names by hand in your program. You would be typing wrong letters over data that is still right. Fix the map, not the names.

Last, when you archive a tree for the long term, store a UTF-8 copy. Maps go out of use — ANSEL is proof. UTF-8 is the safest long-term bet the field has, and a 7.0 copy is UTF-8 by rule. The storage routine is covered in how to back up your family tree.

Frequently Asked Questions

Are my ancestors' names lost when they show garbled? Almost never. The bytes are still in the file. They were read with the wrong map. Read with the right map and the names return, whole. Hand-typing over them is the one move that can cause real loss.

Why did this happen when I moved to a new program? The old program wrote one map, or wrote its CHAR line loosely. The new program trusts the CHAR line or guesses a different default. The file did not change in the move; the reader changed.

What is the difference between ANSEL and UTF-8 for my tree? ANSEL holds accented Latin letters in a two-part form and cannot hold many alphabets at all. UTF-8 holds all alphabets in one map. If your tree is all Western European names, both can work. If it reaches further, only UTF-8 is safe.

Can I just change the CHAR line to UTF-8? Only if the bytes already are UTF-8. The CHAR line is a label. Changing the label on ANSEL bytes makes the lie worse, not better. Convert the bytes, then set the label to match.

Why does Excel garble the names in my CSV too? Excel on Windows guesses the map of a CSV file, and often guesses Windows-1252. A UTF-8 file with a byte order mark at the start tells Excel the truth. That is why GedConvert writes its CSV files that way.

Does GEDCOM 7.0 end encoding errors? It ends the mismatch class: one map, no label to lie. Files can still arrive double-encoded from older mishandling, but new files made as 7.0 start clean.

References

• https://gedcom.io/ — The home of the GEDCOM standard, whose 7.0 spec sets UTF-8 as the only encoding and whose 5.5.1 spec defines ANSEL use.
• 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, and a historic user of ANSEL in cataloging.