CSV Opens With Garbled Characters in Excel: Fix the Encoding

You export a CSV from a bank portal, a shop backend, a lab instrument, or a colleague’s Mac. You double-click it. The columns are right, the text is wrong: Müller shows as Müller, Café as Café, apostrophes turn into ’, and a column of Japanese or Greek names becomes rows of ????? or empty boxes.

Nothing has been corrupted. Excel read every byte correctly and then decoded them as the wrong character set. That is a fixable mistake — but it has to be fixed in the right order, because one of the obvious moves destroys the data for good.

Why a CSV looks like garbage in Excel

A .csv file is plain text with commas. Unlike .xlsx, it carries no metadata about which character set it uses — no header saying “this is UTF-8”. Whatever program opens it has to guess.

Excel on Windows guesses with the system’s ANSI code page — Windows-1252 on most Western installs, 936 on Simplified Chinese, 932 on Japanese. It only departs from that guess when the file starts with a byte-order mark, the three bytes EF BB BF that announce UTF-8.

So a UTF-8 file saved without a BOM gets decoded as Windows-1252. Every accented character is two bytes in UTF-8, and each of those bytes is a legal Windows-1252 character on its own, so nothing fails and nothing warns. You get the classic doubling: é is C3 A9, which renders as é; the typographic apostrophe ’ is E2 80 99, which renders as ’; £ becomes £. If you see that pattern, the file is UTF-8 and Excel is misreading it, and the diagnosis is settled.

The other direction looks different: a Windows-1252 or Shift-JIS file read as UTF-8 produces � replacement characters or ? marks. Same class of problem, opposite fix.

Fix 1 — Import the file instead of opening it

Stop double-clicking. Data → From Text/CSV (Excel 2016 and later, or Data → Get Data → From File → From Text/CSV in Microsoft 365) opens a preview dialog with a File Origin dropdown at the top. Set it to 65001: Unicode (UTF-8), confirm the preview shows real characters, then click Load.

That round trip is the whole fix. Excel converts the text properly on the way in, and the result is a normal worksheet you can save as .xlsx — which records its encoding, so the problem does not come back next week.

On Excel 2013 or older, Data → From Text (Legacy) opens the Text Import Wizard: set File origin to 65001: Unicode (UTF-8), choose Delimited, then pick the delimiter on step 2.

Fix 2 — Choose the encoding the file actually uses

The é signature means UTF-8. But sometimes 65001 is the wrong answer, and forcing it on a legacy file produces mojibake in the opposite direction. Old German or French accounting software is usually 1252: Western European (Windows); Japanese systems, 932: Japanese (Shift-JIS); Chinese systems, 936: Chinese Simplified (GB2312).

Try the plausible options and check a row you can verify — a customer name, a city, a currency symbol. The encoding is right when those read correctly.

Fix 3 — Save a UTF-8 copy with a BOM

If you open the same file every week, fix it once so that double-clicking works. A BOM makes Excel recognise UTF-8 without the import dialog.

Two reliable ways. In Notepad, open the file, then File → Save As and set Encoding to UTF-8 with BOM — the plain “UTF-8” entry in current Notepad is deliberately BOM-less. Or from PowerShell:

$c = Get-Content -Raw -Encoding UTF8 .\orders.csv
[System.IO.File]::WriteAllText("$PWD\orders-bom.csv", $c, (New-Object System.Text.UTF8Encoding $true))

The $true is what writes the BOM. PowerShell 7 made Out-File -Encoding utf8 BOM-less, so the explicit call is the version-proof option.

Do this on a copy, not the original. If the source is not actually UTF-8, re-encoding bakes the mojibake into the BOM’d file and the damage becomes permanent.

Fix 4 — Fix the export, not the file

If the file arrives broken every time, the argument is with whoever generates it: ask for UTF-8 with BOM, or for .xlsx instead of CSV, which records its encoding and cannot be misread.

Banks, ERP systems, Shopify and WooCommerce, and most reporting tools have this setting. It is usually labelled “UTF-8” with a separate BOM checkbox, or “Excel-compatible CSV”. If you control the export in Python, open(path, "w", encoding="utf-8-sig", newline="") writes the BOM, and pandas.to_csv(..., encoding="utf-8-sig") does the same.

One caveat: a BOM can appear as stray characters in tools that do not expect it, so ask for it only if Excel is the main consumer.

Fix 5 — The Windows-wide UTF-8 option

Control Panel → Region → Administrative → Change system locale, tick Beta: Use Unicode UTF-8 for worldwide language support, then restart. Every legacy program on the machine now treats plain text as UTF-8, and plain double-clicks start working.

It changes the ANSI code page for the whole system, and applications built around 1252 — some label printers, older CAD and point-of-sale software — start showing mojibake of their own. Test it on a machine you can roll back.

When the characters are already gone

Two failures look like encoding problems and are not.

The first is loss. If you opened a UTF-8 CSV in Excel and saved it as CSV (Comma delimited), Excel re-encoded it to the system code page and every character outside that page became ?. That substitution is one-way; the byte is gone. Re-export from the source system, and copy an unfamiliar CSV before opening it in Excel at all.

The second is a delimiter problem wearing the same clothes: correct characters, but every field crammed into column A. That is a separator setting, not an encoding one — set File Origin to 65001: Unicode (UTF-8) and the Delimiter to comma or semicolon in the same import dialog. European exports use semicolons more often than people expect.

A damaged CSV is a different matter from a damaged workbook. Plain text has no internal structure to rebuild, so if the bytes are wrong there is nothing for a repair to work with. If the damage sits inside an .xlsx — text already flattened to é in the cells — that is something we can work through: send it over with the original export alongside it. And if the file will not open at all rather than opening wrong, work through Excel file won’t open first; encoding problems leave the structure readable.

FAQ

The file has one long column and no commas. Is it corrupted?

No. The delimiter is not what Excel expected. Use Data → From Text/CSV and set it explicitly rather than relying on the automatic guess.

Will UTF-8 break anything if I switch a recurring export to it?

Not for reading in Excel. Saving as CSV UTF-8 (Comma delimited) keeps every character, but systems expecting the local code page can trip on the BOM, so confirm before changing a feed someone else consumes.