Why Your CSV Shows é Instead of é (and How to Fix It)

Your file is almost certainly fine. In the overwhelming majority of cases the bytes on disk are correct and the program reading them guessed the wrong character encoding — so the fix is to reopen the file with the right one, not to repair the text.

Which fix you need depends on exactly what you are seeing. é is a display mistake you can undo in seconds. A ? where a letter should be is data that has already been thrown away. Those look equally broken on screen and need opposite responses, so start by reading the symptom precisely.

Which garbled pattern are you looking at?

The first row is by far the most common, and it has a giveaway: every mangled character begins with Ã, Â, â or ð. If your file is full of those, nothing is lost and the rest of this article takes five minutes.

Why UTF-8 text turns into é

Text is stored as numbered bytes, and an encoding is the lookup table that says which number means which character. UTF-8 spends more than one byte on anything outside the basic Latin alphabet. Windows-1252 — the legacy "ANSI" table many Windows programs still fall back on — spends exactly one byte on everything and has a character for almost every value, so it never refuses to open a file. It just reads each byte of a multi-byte character as a separate letter.

That single fact explains every pattern in the table:

Read the second row back: C3 is Ã and BC is ¼ in that table, so German text full of ü comes out as ü every single time. The mangling is mechanical, which is why it is reversible — the bytes never changed, only the table used to read them.

Two related notes worth having:

• Latin-1 and Windows-1252 are not the same table. ISO-8859-1 leaves the range 80–9F as control characters, while Windows-1252 fills it with curly quotes, dashes and the euro sign. That is why ’ appears in one and a gap or an invisible control character in the other.
• A CSV file cannot tell you its own encoding. The format specifies punctuation — commas, quotes, line endings — and nothing about the character set, so every program that opens one is guessing from your system settings unless you tell it otherwise. That is the whole root of this problem, and it is also the case for plain-text exports generally; structured formats like JSON at least default to UTF-8, as covered in reading an API response correctly.

How do I open a CSV with the correct encoding?

In Excel, do not double-click the file. Double-clicking hands it to the legacy importer, which uses your system's ANSI code page and never asks. Instead: open Excel first, then Data ▸ From Text/CSV, choose the file, and set File Origin to 65001: Unicode (UTF-8). The preview pane updates live, so you can see the accents come back before you commit. The same dialogue lets you set the delimiter, which fixes the "everything in one column" symptom at the same time.

In Google Sheets, use File ▸ Import rather than pasting. Sheets reads UTF-8 by default, which gives you a free diagnostic: a file that looks right in Sheets and wrong in Excel is UTF-8 without a BOM, and the problem is on the Excel side.

In a text editor (Notepad++, VS Code, Sublime and similar), look for a "reopen with encoding" command rather than a "convert to" command. Reopening re-reads the same bytes with a different table. Converting rewrites the bytes and can bake the damage in permanently — the difference matters enormously, and the menu items sit next to each other.

On the command line, iconv -f WINDOWS-1252 -t UTF-8 in.csv > out.csv converts a genuinely Windows-1252 file. Run it on a copy, because a wrong guess here is destructive.

How do I export a CSV that Excel opens correctly?

Save it as UTF-8 with a byte order mark. The BOM is a three-byte marker at the very start of the file that says "the following is UTF-8", and Excel looks for it. In Excel's own Save As dialogue, the option is named CSV UTF-8 (Comma delimited) — that variant writes the BOM; the plain CSV (Comma delimited) option does not.

The trade-off is real, though, so choose by audience:

• A human opening it in Excel: write the BOM. Without it, Excel guesses your system code page and the accents break again.
• A script, a database import, or another system: usually no BOM. A parser that is not expecting one reads it as part of the first field, which is how a header called id becomes id and how a lookup on that column silently returns nothing.

If you control both ends, prefer UTF-8 without a BOM and set the encoding explicitly on import. If you are emailing a file to a colleague who will double-click it, write the BOM and save both of you the conversation.

What if the accents are already gone?

Two of the symptoms in the table are not display problems, and no amount of reopening will bring the text back.

Question marks. When text is converted into an encoding that has no slot for a character, most tools substitute ?. The letter was not hidden; it was discarded at conversion time. Recovery means going back to the source system and exporting again with UTF-8 selected.

Replacement characters. The � symbol is what a UTF-8 decoder writes when it meets a byte sequence that cannot be valid UTF-8 — usually because the file was actually Windows-1252 all along. If the file is still on disk untouched, reopen it as Windows-1252 and the characters return. If someone has already opened it, seen the diamonds and saved, those bytes have been replaced and the original characters are unrecoverable from that copy.

There is one salvage route worth knowing for the é family specifically. If a mangled file was saved in that state, the damage is still mechanically reversible: re-encode the text as Windows-1252 to get the original bytes back, then decode it as UTF-8. It works because the mangling never lost information. It stops working the moment anything in the file was replaced by ? or �, or anyone hand-edited a few characters — which is the strongest practical argument for fixing the export rather than repairing the file. The same reasoning applies to any text pipeline; our text tools guide covers where encodings sit alongside case, slugs and word counts.

FAQ

Can I just find-and-replace é with é? For a handful of accented characters in a file you will never regenerate, yes — but do it knowingly. Real text usually contains several distinct manglings (accents, curly quotes, dashes, non-breaking spaces), so a partial clean-up leaves a file that looks fixed and still breaks downstream. Reopening with the right encoding fixes all of them at once.

Why does the file look right in my text editor but wrong in Excel? Your editor is defaulting to UTF-8 and Excel is defaulting to your system code page. The file is unchanged between them; only the assumption differs. This is the clearest confirmation that you have a UTF-8 file without a BOM.

Should I put a BOM in every CSV I export? No. Write it when a person will open the file in a spreadsheet, and leave it out when a program will parse it. A BOM in a machine-read file is a common cause of a mysteriously unmatched first column.

Are UTF-8 and "UTF-8 with BOM" different encodings? No — the character encoding is identical. The BOM is three extra bytes at the front, so any tool that does not skip them treats them as content. That is the entire difference, and the entire problem.

My dates broke in the same file. Is that the same cause? No, that is a separate spreadsheet behaviour: dates are stored as day-count serial numbers and the display format is applied on top, which is explained in why spreadsheet dates turn into numbers. Encoding affects letters; the date issue affects number formatting.

Read the symptom, then act: the Ã family means reopen, a ? means re-export, and a BOM means pick a side based on who opens the file. For quick conversions and text checks like this one, see what Medley Web is building.