GedMend › Guides

Why accented names garble when you merge two GEDCOM files

Müller arrives as something else, José loses his accent, and it is always the names you were most careful about. Here is why, and how to catch it before the merge rather than after.

Last updated 26 August 2026

The four schemes you will meet

Encoding	What it is
UTF-8	The modern one. Handles every language, and what a merged file should generally be written in.
UTF-16	Also modern, less common in genealogy. Files usually begin with a short marker announcing the fact, though not always.
ANSEL	An old library-cataloguing encoding that the original GEDCOM standard chose. Almost nothing outside genealogy has heard of it. It is the source of most accent trouble.
Windows-1252	A Western-European encoding, and the usual fallback when a file gives no usable clue about itself.

Why ANSEL breaks things

Modern encodings store an accented letter as one thing: é is a character. ANSEL stores it as two, and puts them in the order a typesetter would — the accent first, then the letter it sits on.

So a program that reads an ANSEL file while assuming a modern encoding sees the accent mark as a standalone character and the bare letter after it. Depending on what it does next, the name arrives with a stray symbol in front of the vowel, with a question mark or a replacement box, or with the accent silently dropped. All three are wrong in different ways, and only the first is obvious enough to notice.

This is also why the damage concentrates in exactly the names you care most about. Plain ASCII names pass through every encoding unharmed. It is Müller, José, Ó Briain, Łukasz and Ångström that suffer — the ones where the accent is part of the identity.

How to check your own files, in five minutes

You do not need to know what encoding a file uses. You need to know whether the names came out right, and that is directly observable.

1. Pick three or four people whose names carry accents — an umlaut, an acute, a cedilla, a slashed O. If you cannot think of any, sort your surname list and look at the end; unusual characters cluster there.
2. Look at them wherever the tool shows you names — the file summary, the match list, the person cards. Encoding problems show up in exactly one place: the display of text. They do not affect dates or numbers.
3. Judge what you see. If the accents are right, the file decoded correctly and you can proceed. If you see a stray letter in front of the vowel, a question mark, or a replacement box, that file is mislabelled at source.

If a file is wrong

Fix it where it came from, not downstream. Re-export it from the program that produced it, choosing UTF-8 if the program offers a choice. A file exported correctly is right for good; a file patched afterwards is right until someone opens it in the wrong program.

If you cannot re-export — the file is inherited, the program is gone, the person who made it is not reachable — then note which names are affected before you merge, so you can correct them by hand afterwards and know when you are done. A short list beats a search through twelve thousand people.

Different encodings in the two files is normal

It is worth saying plainly, because the warning sounds more alarming than it is. Two files using different encodings is an entirely ordinary situation — your own tree exported by modern software, their file exported by a program from 2003 — and it is handled by converting both to one scheme on the way in. The warning exists so that you go and look at the accented names before the merge rather than discovering the problem in the output.

What is not ordinary, and is worth stopping for, is a name that displays wrongly on the screen. That means one of the inputs is already damaged, and merging will faithfully carry the damage forward.