Logo

Fix: Accented Characters Broken in Excel CSV (UTF-8)

You open a perfectly valid UTF-8 CSV and "José" reads as "José", "café" reads as "café", or "München" reads as "München". The file isn't corrupted, this is Excel guessing the wrong encoding. Here's the free, exact fix.

Why this happens

UTF-8 encodes accented characters using two or more bytes. When you double-click a .csv, Excel doesn't reliably detect UTF-8, on Windows it often falls back to the system's ANSI code page (typically Windows-1252). Each UTF-8 byte then gets reinterpreted as a separate Windows-1252 character, producing exactly the pattern you're seeing: one accented letter turning into two or three garbled ones (this is called mojibake).

The fix: import instead of double-clicking

  1. Don't double-click the file. Open a blank Excel workbook first.
  2. Go to Data → Get Data → From File → From Text/CSV (Excel 2016+) or Data → From Text (older versions).
  3. Select your CSV file.
  4. In the preview dialog, find File Origin and change it to 65001: Unicode (UTF-8). The preview should immediately show the correct accented characters.
  5. Click Load (or Import in the older wizard).

This works even if the file has no BOM, you're explicitly telling Excel the encoding instead of letting it guess.

If you're generating the CSV yourself (Python, Node.js, exports)

Save the file with a UTF-8 BOM instead of plain UTF-8, so a simple double-click in Excel also works correctly, without forcing every recipient through the import wizard:

# Python
with open("output.csv", "w", encoding="utf-8-sig", newline="") as f:
    writer = csv.writer(f)
    writer.writerow(["name", "city"])
    writer.writerow(["José", "München"])

utf-8-sig writes the three-byte BOM (EF BB BF) at the start of the file. Excel on Windows treats that as an explicit UTF-8 signal and decodes correctly on double-click, no import wizard needed.

If the data is already garbled (mojibake), not just displayed wrong

There's a difference between "displayed wrong, but the underlying bytes are fine" (fixed by the import method above) and "actually corrupted because the file was re-saved with the wrong encoding" (double-encoding). If you re-open the file in a plain text editor and still see "José" instead of "José", the file itself has been mangled and needs to be regenerated from the original source, re-importing with the correct source encoding won't recover data that's already been double-encoded and saved.

If you don't have the original source, our Change Encoding tool can detect the actual byte-level encoding a file is in (including common mis-encodings) and re-save it correctly, entirely in your browser, without uploading the file anywhere.

This isn't only about accents

The same mojibake pattern shows up for any character outside the basic ASCII range, not just accented Latin letters. Curly "smart" quotes (“ ”), em dashes (—), currency symbols like € or £, and non-Latin scripts (Cyrillic, Greek, CJK characters) all get mangled the same way when Excel misreads a multi-byte UTF-8 sequence as single-byte Windows-1252. If you're seeing something like â€" where an em dash should be, or € instead of a euro sign, it's the identical root cause, and the same Data → From Text/CSV fix applies regardless of which character is affected.

Fixing many files at once

Re-importing one file through the wizard is fine for a single case, but it doesn't scale if you regularly receive a batch of misencoded exports from the same source (a legacy system, a partner's nightly export). In that situation it's worth fixing the encoding at the file level before anyone opens it in Excel at all:

  • Detect the actual source encoding once (often Windows-1252 or ISO-8859-1 for Western European exports), then batch re-save every file as UTF-8 with BOM before distributing them.
  • If the source system can be configured, changing its export encoding to UTF-8 (with BOM, for Excel compatibility) removes the problem permanently instead of requiring a fix on every file it produces.
  • Where you don't control the source and can't standardize on one encoding, treat "detect and convert" as a mandatory last step before any file is shared or imported, not an optional cleanup step.

Doing this in How To CSV

The free Change Encoding tool detects a CSV's real encoding and converts it to clean UTF-8 (with or without BOM) in your browser, no sign-up, no upload. For a deeper look at encodings in general, see the CSV encoding issues guide, and if the file has structural problems beyond encoding (ragged rows, stray quotes), CSV Lint gives a full line-by-line report.

Fix the encoding now, free

Detect and correct a CSV's encoding in your browser. No upload, no sign-up.

Fix Encoding

Turn this into a saved workflow

Create a free account to save the steps from this guide as a reusable workflow and re-run it on any file, from any device.

Sign in for free

Follow HowToCSV on Google

Add us as a preferred source on Google Search so our latest CSV guides and tutorials surface more often in your Top stories.

Add HowToCSV as a preferred source