Seeing é Instead of é? How to Fix Broken CSV Characters

Updated July 24, 2026 · By the CSVUndo team · 8 min read · Applies to Excel 2010–365, Google Sheets, and any CSV workflow

You export a customer list from your database or CRM. It looks perfect in the source system. Then you open the file in Excel and every café has become café, every José is now José, and the quotation marks have exploded into “. This garbling has a name — mojibake, Japanese for “character transformation” — and the good news is that it is almost always fully reversible. Nothing was deleted. Every byte of your original text is still in the file; it is just being read with the wrong decoder.

The symptom: two junk characters per accent

Mojibake follows a pattern so consistent you can diagnose it at a glance. Every accented Latin letter turns into exactly two characters, and the first is usually a capital Ã:

• café → café
• José → José
• München → München
• François → François

Punctuation pasted from Word or a web page breaks into three characters, because those symbols sit further out in Unicode. Curly quotes become “ and â€, apostrophes become ’, and dashes become –. So a cell that should read “It’s ready” shows up as “It’s readyâ€. If your file is peppered with Ã, â€, or a stray Â before spaces and degree signs, you are looking at one disease with one cure.

The cause: UTF-8 bytes read as Windows-1252

In plain terms: the program that wrote your file and the program that read it disagreed about what the bytes mean. Your database or export script wrote the file in UTF-8, the encoding used by essentially the entire modern web. Excel opened it assuming Windows-1252, the single-byte encoding Windows has used for Western languages since the 1990s.

Now precisely: UTF-8 stores é as two bytes, 0xC3 0xA9. Windows-1252 assigns one character to each byte, so a program reading the same file as Windows-1252 renders the pair separately: 0xC3 maps to Ã and 0xA9 maps to ©. One character in, two characters out — é. Characters that need three UTF-8 bytes, like curly quotes and the euro sign, shatter into three junk characters by the same logic.

Excel is the usual culprit because of how it opens CSVs. Double-click a .csv file and Excel never asks about encoding — it assumes your system’s legacy ANSI code page unless the file happens to begin with a UTF-8 byte order mark. No BOM, no dialog, instant mojibake.

Corruption reference table

Use this table to confirm the diagnosis. Find a garbled sequence from your file in the right-hand column; if it matches, the file is UTF-8 being misread as Windows-1252 and the repair below will work.

The right curly quote looks like it lost a character because its final byte, 0x9D, has no printable glyph in Windows-1252 — most programs simply hide it. The byte is still there, which is why automated repair still recovers the quote.

Double mojibake: when it happens twice

Sometimes you will find é where a single é should be — four junk characters instead of two. That is double mojibake: the same corruption applied twice over.

Here is the mechanism. A file gets mangled once (é → é) and someone saves the result, so the junk characters become real text. Later that file is saved as UTF-8 — giving Ã and © multi-byte sequences of their own — and then read as Windows-1252 a second time, splitting those bytes apart again: é → é → é. It is common in data that has bounced between a CRM export, an Excel edit, and a re-import. The damage is still deterministic and still reversible; it just has to be unwound twice, in order.

Fix it now in your browser

You could build find-and-replace rules for every row of the table above, but you would miss sequences the table does not show — there are hundreds of possible pairs. The CSVUndo broken character fixer takes the reliable route instead: it reverses the byte transformation itself, re-encoding the garbled text to Windows-1252 bytes and decoding them as the UTF-8 they always were. Every mojibake sequence in the file snaps back at once.

Prevent it in Excel

Repairing once is fine; the durable win is stopping Excel from misreading files in the first place.

Importing: never double-click

Open a blank workbook and use Data → From Text/CSV instead of double-clicking the file. In the import dialog, set File origin to 65001: Unicode (UTF-8). The preview updates instantly — when José turns back into José, you have the right setting. Click Load. In Excel 2013 and older, the equivalent is the Text Import Wizard (Data → From Text), which offers the same File origin dropdown at step 1.

Saving: pick the UTF-8 variant

When you save, choose CSV UTF-8 (comma delimited) (*.csv) from the file type list — not the plain “CSV (Comma delimited)” entry, which writes Windows-1252 and silently swaps any character that does not fit for a question mark. That substitution, unlike mojibake, is permanent.

Why the BOM matters

The “CSV UTF-8” option also writes three invisible bytes — EF BB BF, the byte order mark — at the very start of the file. Those three bytes are the only signal a double-clicked file can give Excel that it contains UTF-8; without them Excel falls back to the legacy code page and you are back to é. Some other tools, though, trip over a BOM they do not expect. Our guide to UTF-8, the BOM, and Excel covers when to add one and when to strip it.

One last gotcha: if you fix the encoding and Excel then dumps every field into a single column, that is a separate problem — a delimiter mismatch between the file and your regional settings — with its own one-minute fix.

FAQ

Related reading: UTF-8, BOM and Excel explains the three-byte marker behind most of these accidents, and CSV opens in one column covers the delimiter problem that often travels with encoding trouble. Ready to repair? Fix your broken characters now — free, local, and reversible-damage-only by design.