Why Excel shows “é” instead of “é” in your CSV
What UTF-8, Windows-1252 and the byte order mark are, why Excel guesses wrong, and how to export a CSV that opens correctly everywhere.
A CSV file is just text, and text on disk is bytes. The file does not say which encoding turns those bytes back into letters, so every program has to guess. When it guesses wrong, accented letters and symbols turn into pairs of strange characters.
The two encodings you will meet
- UTF-8 can store every character in every language.
éis two bytes. Most web apps, databases and exports use it today. - Windows-1252 (often called “ANSI”) stores one byte per character and only knows Western European letters. Older Excel versions and many accounting tools still save CSVs this way.
é is what the two UTF-8 bytes of é look like when a program reads them as Windows-1252. The data is not damaged; it is being read with the wrong key.
Why Excel gets it wrong
When you double-click a CSV, Excel on Windows assumes your system’s legacy encoding unless the file starts with a byte order mark (BOM), three invisible bytes that say “this is UTF-8”. Many exporters leave the BOM out, so Excel guesses Windows-1252 and the accents break.
The fix
- Open the file in GridRinse. It tries strict UTF-8 first and falls back to Windows-1252 when the bytes are not valid UTF-8, and tells you which one it used.
- Clean it as usual.
- Download as CSV with Excel-friendly (UTF-8 BOM) ticked (the default). Excel then opens accents correctly, and other tools ignore the BOM. If a system you upload to rejects the BOM, untick it, or download XLSX, which has no encoding question at all.
Separators are a related trap
In countries that write decimals with a comma, Excel expects semicolons between columns. If everything lands in column A, export with the semicolon separator, or use XLSX.