Fix Broken Characters in Your CSV — é Back to é

What is mojibake?

Mojibake (a Japanese loanword meaning roughly “transformed characters”) is what you get when text written in one character encoding is read using a different one. In the CSV world one flavor dominates: a file saved as UTF-8 — the default for practically every database, web platform, and export API — gets opened by a program assuming Windows-1252, the legacy one-byte encoding Excel still falls back to on most Windows machines.

Plain letters, digits, and commas survive, because the two encodings agree on those. But every accented letter, curly quote, dash, and currency symbol comes out as two or three wrong characters, usually starting with Ã, Â, or â. The crucial point: nothing was deleted — the original bytes are still in the file, just read with the wrong dictionary. That’s why this damage, unlike Excel’s scientific-notation mangling or deleted leading zeros, is fully reversible.

The exact mechanics: how é becomes é

Take the letter é. Unicode holds over a million characters, so UTF-8 stores é as two bytes: 0xC3 0xA9. Windows-1252 is strictly one byte per character, so a program reading in 1252 mode treats each byte as a standalone character:

• 0xC3 is Ã in Windows-1252
• 0xA9 is © in Windows-1252

So José renders as José — one real character split into two impostors. Typographic punctuation fares worse, because curly quotes and dashes need three bytes each: the left quote “ is stored as 0xE2 0x80 0x9C, which 1252 mode reads as â, €, and œ — the infamous “.

The typical chain of events: someone exports orders.csv from Shopify or a database (UTF-8), a colleague double-clicks it on Windows, Excel silently decodes it as Windows-1252, they fix one price and hit Save — and the garbage is now written into the file itself.

Common corruption pairs

Spot any of these patterns in your data and the tool above will reverse them:

A quirk worth knowing: the right curly quote ” ends in byte 0x9D, which Windows-1252 leaves undefined — so it often shows up as â€ followed by nothing, a box, or a question mark. The repair handles that case too.

Double-encoded files: when é becomes é

Files that pass through more than one careless program sometimes show longer monsters like é where é should be. That’s double encoding: the file was corrupted once (é → é), then the corrupted text was itself saved as UTF-8 and misread as Windows-1252 a second time (é → é). Every round trip roughly doubles the junk. It looks hopeless, but it’s just the same mistake stacked — the repair engine runs its reversal pass repeatedly until the text stops changing, so double- and even triple-encoded cells come back clean in one click.

How the repair works — without touching real text

The naive fix would be a find-and-replace list: swap every é for é and hope. That’s risky, because Ã, â, and friends are legitimate letters in Portuguese, French, Romanian, and Vietnamese text. CSVUndo does something much stricter:

1. Each character in a suspicious cell is mapped back to the Windows-1252 byte it would have come from. If any character has no 1252 byte, the cell can’t be mojibake and is skipped.
2. The reconstructed bytes go to a strict UTF-8 decoder with fatal error checking enabled. Only if they form completely valid UTF-8 is the decoded text accepted as the real content.
3. If decoding fails at any byte, the cell is left byte-for-byte untouched.

Genuine text essentially never passes that test by accident. The Portuguese word não maps back to bytes 6E E3 6F — and 0xE3 without two continuation bytes is illegal UTF-8, so the decoder throws and não stays exactly as it is. Cells that mix genuine Unicode with mojibake fragments are handled word by word, and the fixed file downloads with a UTF-8 BOM so Excel opens it correctly next time.

Preventing it next time

Two habits eliminate mojibake permanently:

1. Never double-click a CSV that came from the web. Open a blank workbook, use Data → From Text/CSV, select the file, and set the File Origin dropdown to 65001: Unicode (UTF-8). The preview updates instantly — when José looks right, click Load. On Excel 2013 and older, the legacy Text Import Wizard (Data → From Text) offers the same 65001 choice in step 1.

2. Save as “CSV UTF-8”, not plain “CSV”. In File → Save As, pick CSV UTF-8 (Comma delimited) (*.csv). The plain CSV option writes your system’s legacy ANSI code page and destroys any character it can’t represent.

Why does Excel need help at all? On a double-click, Excel runs no encoding detection — it assumes the machine’s ANSI code page (Windows-1252 across the Americas and Western Europe) unless the file begins with the three-byte signature EF BB BF, the UTF-8 byte order mark. With the BOM present, Excel decodes UTF-8 correctly. That’s why this tool writes the BOM by default; tick “Skip UTF-8 BOM” only if the file is headed to a system that chokes on it. Our guide on the UTF-8 BOM and Excel covers the trade-offs in detail.

Related reading and tools: the full walkthrough Why does é appear instead of é? digs deeper into diagnosis, and if Excel also mangled your numbers, the scientific notation fixer and the leading zeros restorer repair those in the same way — free and entirely in your browser.

Frequently asked questions