GEDCOM Encoding Problems: Why Names Look Garbled After Upload

If accented or non-Latin characters in your family tree turned into stray symbols, question marks, or boxes after an upload or transfer — a name like "José" showing up as "Jos©" or "François" as "François" — this is almost never data corruption in the sense of lost information. It's a program reading the right bytes with the wrong assumption about what character set they represent.

Why this happens

Text in a computer file is stored as numbers; a character encoding is the agreed-upon rule for which number means which letter. GEDCOM 5.5.1 allows several different encodings — UTF-8, UTF-16, and an older genealogy-specific encoding called ANSEL, built to handle the accented and special characters common in family history records. Every 5.5.1 file is supposed to declare which one it uses, in a CHAR line in the file's header.

The garbling happens when that declaration is missing, wrong, or simply ignored by the program reading the file. If a file was actually written in ANSEL but a program reads it assuming UTF-8 (or vice versa), every character outside plain A-Z gets reinterpreted as the wrong symbol. The underlying data isn't gone — it's just being decoded with the wrong key.

Where this most often goes wrong

Old exports meeting new software. ANSEL was common in genealogy software from the 1990s and 2000s. If you're opening or uploading a file exported years ago, there's a real chance it's ANSEL-encoded even if nothing in the filename or your memory of the program suggests it. See ANSEL Encoding Explained for exactly what this encoding is and why it still shows up in older files.

A mismatched or missing CHAR declaration. Some programs write an inaccurate CHAR tag — carried over from a template, or defaulted incorrectly — so even a technically well-formed file lies about its own encoding. A reading program that trusts the declaration will then decode everything wrong from the very first accented character.

Multiple hops through different software. Every time a GEDCOM file passes through another program — export, re-import, re-export — there's a chance the encoding gets silently reinterpreted or converted incorrectly. A file that looked fine after the first export can pick up garbling two or three transfers later, which makes the original cause harder to spot.

How to actually fix it

Start by checking what the file's header actually declares versus what encoding was likely used when it was created — a plain text editor will show you the raw CHAR line. If you have access to the original software that exported the file, re-exporting with UTF-8 explicitly selected (where the option exists) is the cleanest fix, since UTF-8 is universally supported by current genealogy software and by FamilySearch.

If you no longer have the original software, or the garbling is already baked into the file you have, the Upload Readiness Checker reads your file's declared encoding and flags it as part of its diagnostic report — including whether that declaration looks reliable — before you spend time uploading a file that's going to come out wrong on the other end. This is also one of the structural issues covered generally in Common GEDCOM Upload Error Messages, Explained, since an encoding mismatch is a real cause of upload problems independent of file size or individual count.