CSV Garbled in Excel

You open a CSV in Excel and the text comes out as été, ë³´ê³ ì„œ, or 文字. If the same file looks perfectly fine in Notepad or a code editor and only breaks in Excel, the file is not the problem. Excel is.

Why only Excel breaks it

Computers store characters as numbers, and there are many different tables mapping between the two. The modern standard is UTF-8, but Windows has long used regional tables — CP1252 in Western Europe, CP949 in Korea, CP932 in Japan. The same numbers read through a different table come out as different characters.

The trouble is that a CSV file has no place to record which table it used. It is just characters, one after another. So every program has to guess, and while most editors now assume UTF-8, Excel falls back to the local Windows code page whenever the file carries no marker. Text saved as UTF-8 gets read through a regional table, and you get nonsense.

This is why CSVs exported from websites, databases, and Python scripts break so reliably. Those tools almost always write UTF-8 — and almost never add the marker.

Three bytes fix it

A BOM (Byte Order Mark) is a three-byte marker at the very start of the file. It is invisible and changes nothing about the content, but with it in place Excel recognises the file as UTF-8 and reads it correctly.

Which means fixing a garbled CSV is usually not about changing the text at all — it is about adding the marker. The content was intact the whole time.

Fixing it with this tool

Open Mojibake Recovery, switch to the File tab, and upload the CSV. It identifies the encoding and shows you candidates. Pick the one where the text reads correctly and press Download as UTF-8.

Check that "Add a BOM if you will open this in Excel" is ticked. It is on by default for .csv, .tsv, and .txt. A file downloaded with that option on opens cleanly in Excel with no further steps.

Your file is never uploaded anywhere. Everything runs inside your browser, so internal reports and files with personal data are safe to use here.

When the file itself uses a legacy encoding

The reverse happens too. A CSV written by an older program may genuinely be stored in a regional encoding, and it breaks the moment something expects UTF-8 — modern Python, Google Sheets, Numbers on macOS.

The same route fixes it. Upload the file and the correct legacy encoding comes up as the top candidate; download it as UTF-8 and every modern tool can read it. Either way, uploading the file is the first move — the tool works out which direction you are in.

Saving files that will not break again

When exporting from Excel to share with others, choose Save As → CSV UTF-8 (Comma delimited), not plain CSV (Comma delimited). The plain option writes the local code page, which breaks for anyone on macOS or Linux.

If you generate the file yourself, save as UTF-8 with the BOM option enabled. In Python that is encoding='utf-8-sig'.

If none of this helps

If the characters look right but every row lands in a single column, that is a delimiter problem, not an encoding one. Use Data → Text to Columns and set the comma as the separator.

If none of the candidates show readable text, the file may have been written after the text was already garbled. In that case see the "When recovery fails" section on the tool page, which lists the symptoms and what each one means.