Outlook or Google Contacts Turned José Into José? Fix the CSV Encoding First

Last updated: August 2026 · By the CSVUndo team · 9 min read

Contacts import as José when the program reading your CSV decodes it with the wrong character encoding: Outlook’s legacy import wizard falls back to Windows-1252 (ANSI) for a UTF-8 file that carries no byte order mark, while Google Contacts reads everything as UTF-8 and garbles ANSI files. The names inside the file are almost always still intact — the damage happens at decode time, not on disk. Fix the file’s encoding once, before you import, and every contact arrives spelled correctly; the free browser tools linked below do it in about a minute.

Why did Outlook import José as José?

Because the file is UTF-8 and Outlook’s Import/Export wizard read it as ANSI. The wizard behind File → Open & Export → Import/Export → Import from another program or file → Comma Separated Values in classic Outlook is old code. (New Outlook and Outlook on the web import from People → Import contacts instead, and Microsoft’s advice there is the same: give it a UTF-8 file.) Unless the file announces itself with a UTF-8 byte order mark, the wizard decodes it with your system’s legacy ANSI code page — Windows-1252 on most machines in the Americas and Western Europe. Almost every contacts CSV you meet today is UTF-8, because that is what Google Contacts, iCloud, CRMs, and web apps export. The mismatch is baked in before you click a single button.

The mechanics are simple and completely predictable. UTF-8 stores é as the two bytes 0xC3 0xA9; Windows-1252 assigns one character per byte, so those two bytes render as Ã and ©. That is how José becomes José, Müller becomes Müller, and François becomes François. Curly apostrophes in company names shatter into three characters, ’, because they need three UTF-8 bytes. The full byte-level walkthrough lives in why é appears instead of é.

UTF-8 stores most accented Latin letters as two bytes, so one wrong decode usually turns each accent into two junk characters — and letters outside that range, such as the ễ in Nguyễn, take three bytes and become three. Either way, a single bad import setting can garble a 1,000-name contact list in hundreds of places at once.

The reassurance matters as much as the diagnosis: the CSV on your disk is still correct. Open it in Notepad or VS Code — editors that auto-detect UTF-8 — and José reads perfectly. Nothing needs retyping; the file just needs to reach Outlook in a form the wizard cannot misread, which is what the fix below does.

Why does Google Contacts show Jos� or Jos? instead of José?

This is the same accident running in the opposite direction: an ANSI file decoded as UTF-8. Google does not document the encoding its importer expects, but in practice Google Contacts reads every uploaded CSV as UTF-8. In a Windows-1252 file, é is the single byte 0xE9 — and a lone 0xE9 is not a legal UTF-8 sequence. Google’s strict decoder cannot interpret it, substitutes the Unicode replacement character �, and many contact screens then draw that as a plain question mark. José goes in; Jos� or Jos? comes out.

Where do ANSI contact files come from in 2026? Mostly from Excel: the plain “CSV (Comma delimited)” save writes your system’s legacy code page, not UTF-8. A CSV that came out of Outlook is not guaranteed to be UTF-8 either, which is why a list that came out of Outlook so often garbles on its way into Google. The difference between the two formats — and why the 256-character ANSI set cannot hold most of the world’s names — is covered in ANSI vs UTF-8 for CSV files.

As with Outlook, the damage usually happened during the decode, not inside your file. The copy on your computer still says José in its own encoding. Not sure what that encoding actually is? Drop the file on the CSV encoding checker — it reads the actual bytes and tells you — then follow changing a CSV’s encoding to UTF-8 before you upload again.

Which contact-name damage is reversible — and which is gone for good?

Match your symptom first; the four cases look alike but only three can be fixed.

The last row is the one honest limit. Once a program has written a real question mark in place of a character, the original byte no longer exists anywhere in that copy, and no tool — ours included — can reconstruct it. The full story of that failure mode is in CSV shows question marks instead of letters. Everything else on this page is genuinely reversible, because the original bytes are still present and merely mislabelled.

How do I fix the contacts CSV before importing it?

Repair the one file, then import; never plan to clean up inside the address book. The routine takes three steps:

1. Diagnose. Open the CSV in Notepad or check it with the encoding checker. If the names read correctly, the file is healthy and only the encoding label needs handling. If you see José in the file, the garble has been saved into the text and needs reversing.
2. Repair or convert. The broken-character fixer handles both cases at once. Saved mojibake is reversed by mapping each suspect cell back to its Windows-1252 bytes and strictly re-decoding them as UTF-8 — even double-garbled monsters like é come back. And because every repaired file downloads as UTF-8 with a byte order mark, a clean-but-ANSI file that passes through it comes out as exactly the UTF-8 both Outlook and Google want. Leave the “Skip UTF-8 BOM” box unchecked for contact imports: the BOM is precisely the signal Outlook’s wizard needs.
3. Re-import the downloaded file. Same data, right encoding, correct names.

How do I export a contacts CSV in the right encoding to begin with?

Every future import goes right if the export is UTF-8 with a BOM — here is where each program stands.

From Excel: use File → Save As and pick CSV UTF-8 (Comma delimited) (*.csv), never the plain CSV (Comma delimited) entry beside it. The plain option writes ANSI and silently swaps every character outside its 256 slots for a question mark — the one kind of damage nothing can undo. The step-by-step, including older Excel versions, is in saving an Excel file as CSV UTF-8.

From Google Contacts: the export dialog (More actions → Export) offers Google CSV and vCard, and Google documents neither the encoding it writes nor any difference between the formats — so check the download with the encoding checker rather than assuming. In practice a Google export is UTF-8 with no byte order mark, which is why it can garble in Outlook’s legacy wizard: right columns, unannounced encoding. Run the export through the fixer to stamp it with a BOM before importing it into Outlook.

From Outlook: Microsoft does not document the encoding its CSV export writes, so treat its output as suspect rather than guessing: check it with the encoding checker, and convert to UTF-8 before handing it to Google Contacts or any web CRM.

Why does the BOM keep coming up? Those three invisible bytes at the start of a file — EF BB BF — are the only encoding signal a CSV can carry, and legacy importers like Outlook’s wizard fall back to ANSI without them. When to add one and when to strip it is covered in UTF-8, the BOM, and Excel.

Should you fix the file, or edit hundreds of contacts after import?

Fix the file. It is one minute of work against an afternoon — and it is also the only reliable option. Editing after import means opening every affected contact, retyping the name, and saving; a list with a few hundred accented names becomes hours of error-prone cleanup, and any contact you miss keeps greeting its owner as José in every mail-merge from now on.

Worse, update-in-place is shaky precisely when you need it. Import tools match incoming rows against existing contacts by fields like name or email — and when the stored name is garbled, it no longer matches the corrected row, so a re-import tends to create duplicates instead of overwriting the damage. The dependable sequence is: delete the bad batch, then import the fixed file. Google Contacts usually makes the first half easy: an import is normally collected under its own label, so open that label, select all, delete. If no label was created, remove the bad batch manually before re-importing. In classic Outlook, switch the Contacts folder to a list view and sort by Modified to isolate the imported batch before removing it. Then bring in the repaired CSV and the list is clean. Google caps a single import at 3,000 contacts, so split a bigger file first — the CSV splitter does it in the browser.

What about phone numbers and long IDs in a contact CSV?

Encoding damage is reversible; digit damage usually is not — and contact files carry both risks. If the list ever passed through Excel, remember that Excel treats bare digit strings as numbers: it strips leading zeros and the + from phone numbers, and it keeps only 15 significant digits of longer values. Digits Excel truncated past 15 significant places and saved are gone for good — the trailing digits were replaced with zeros on disk, and no tool can recover them. The prevention steps live in phone numbers broken in CSV and 16-digit numbers changed to zeros.

Display-style damage such as scientific notation often can be undone, but never on shape alone: a cell reading 2E5 might be Excel’s mangling of 200000, or it might be a genuine part code, and expanding it on a guess would rewrite real data. That is why the scientific notation fixer only converts values it can prove came from Excel’s formatting and asks you to confirm the rest.

Frequently asked questions

Related reading: why é appears instead of é walks through the byte mechanics with a full corruption table, ANSI vs UTF-8 explains the two formats behind every symptom on this page, and changing a CSV’s encoding to UTF-8 covers the desktop-editor route. Ready now? Fix the contact file and import it once, correctly. More fixes in the CSVUndo guides index.