Developer guide
CSV Encoding Issues: UTF-8, BOM, Excel & Mojibake
You export a CSV from your app, open it in Excel on Windows, and the text looks like é or ÿþ. The data isn't broken — the encoding is mismatched. This guide explains what's happening and the exact fixes, including the one that solves it in 60 seconds.
Written by Benjamin Rotshtein
Updated
- Why does this keep happening?
- CSV has no header that declares its encoding. Excel has to guess, and on Windows it guesses the system locale (Windows-1252) unless it sees a UTF-8 BOM.
- What's the 60-second fix?
- Re-open with Excel's Data → From Text/CSV and choose UTF-8 (code page 65001) explicitly. For a permanent fix, save the file as UTF-8 with BOM.
- Is UTF-8 always the answer?
- For CSV, yes. UTF-8 covers every language, works with every modern tool, and with a BOM is understood by Excel on both Windows and Mac.
Why Excel mangles your CSV
A CSV file is just bytes. To show it as text, a program must decide which character encoding those bytes use. CSV has no built-in way to say "I am UTF-8", so Excel guesses. On Windows it assumes the regional code page (Windows-1252 for most of the West) unless the file starts with a UTF-8 BOM. Guess wrong and every multi-byte character is split into nonsense.
UTF-8 vs UTF-16 vs Latin-1
| Encoding | Bytes per Latin char | Non-Latin scripts | Verdict for CSV |
|---|---|---|---|
| UTF-8 | 1 | Yes (3-4 bytes) | Best choice |
| UTF-16 | 2 | Yes (2-4 bytes) | Doubles size, avoid |
| Latin-1 / Windows-1252 | 1 | No | Legacy, breaks Unicode |
UTF-8 is the standard: every modern programming language and tool writes it by default. Latin-1 is the historical cause of most mojibake — it simply has no representation for Hebrew, Cyrillic, Chinese, or even most accented Eastern European text. UTF-16 is mostly a legacy of Windows internals and buys nothing for a text table except twice the bytes.
What the BOM does
A BOM (byte order mark) is three bytes — EF BB BF — placed at the very start of a UTF-8 file. It's a signature, not a character:
EF BB BF name,city
Alice,BerlinWhen Excel sees it, it opens the file as UTF-8 without guessing. Without it, on Windows, the same bytes are misread. Most editors hide the BOM, so it costs nothing visually — and it is the single most effective fix for Excel mojibake.
The 3 fixes that actually work
1. Open explicitly. In Excel use Data → From Text/CSV, choose the file, and pick Encoding: UTF-8 (code page 65001). This reads the file correctly without changing it.
2. Add a BOM and re-save as UTF-8. Re-export from the source with UTF-8 + BOM enabled (check "include BOM" in your export tool), or open in a modern editor and Save As UTF-8 with BOM.
3. Verify with a hex look. Confirm the file actually is UTF-8: the bytes for é should be C3 A9, not E9. If they're E9, the source wrote Latin-1 and you must fix the source.
Why exported CSVs differ by tool
Google Sheets exports UTF-8 without a BOM. Excel's own CSV save historically used the locale code page, and modern Excel on Windows writes UTF-8 with a BOM. A file that looks perfect in Google Sheets can look broken in Excel and vice versa — because each tool writes a different encoding and reads with a different guess. Converting through a neutral, browser-side tool that writes UTF-8 with BOM removes the guesswork.
Frequently asked questions
Why does Excel show mojibake in my CSV?
Almost always an encoding mismatch. Excel guesses the file's encoding, and without a UTF-8 BOM on Windows it tends to assume the system locale (often Windows-1252). If the file is really UTF-8, accented and non-Latin characters get misread and show as é, ‚ or question marks.
What is the UTF-8 BOM and why do I need it?
A BOM (byte order mark) is a three-byte signature (EF BB BF) at the start of a UTF-8 file. It's how Excel on Windows recognizes the file as UTF-8 instead of guessing. Without it, a UTF-8 CSV commonly opens as garbled text. The BOM is invisible and safe to keep.
UTF-8 vs UTF-16 vs Latin-1: which should I use?
Use UTF-8. It covers every language, is compatible with modern tools, and is the de-facto standard on the web and in code. Latin-1 (Windows-1252) only covers Western European characters and is the most common cause of legacy mojibake. UTF-16 doubles the file size and is almost never the right choice for CSV.
How do I fix a CSV that shows é, ‚ or question marks?
If you see mojibake, re-open the file with the correct encoding: Excel's Data → From Text/CSV lets you pick UTF-8 or 65001 explicitly. For a permanent fix, re-save the file as UTF-8 with BOM, or regenerate it from the source with UTF-8 output enabled.
Why does my Hebrew, Cyrillic or Chinese text get corrupted?
Non-Latin scripts require a Unicode encoding. If the file was saved as Latin-1/Windows-1252 or if Excel decoded UTF-8 bytes as ANSI, every multi-byte character is split or lost. Save as UTF-8 (with BOM for Excel on Windows) and the text arrives intact.
Does column order matter for CSV encoding?
No. Column order is about how the header maps to fields, not encoding. But changing column order can expose an underlying encoding problem you hadn't noticed, because a reordered file re-opened in Excel gets the same misread characters — now in different cells.