CSV UTF-8 & BOM Problems in Excel — How to Diagnose and Fix Them

What UTF-8 is

UTF-8 is a character encoding: a rule for turning text (letters, accents, CJK characters, emoji) into bytes on disk. Most modern exports from web apps, databases, and programming languages use UTF-8. A CSV that is “valid UTF-8” stores those bytes correctly — but an app can still display them wrong if it assumes a different encoding when reading the file.

Plain ASCII (A–Z, digits, basic punctuation) looks the same in UTF-8 and in older Western encodings. Problems show up when the file contains bytes for accented or non-Latin characters.

What a BOM is

A BOM (Byte Order Mark) is a short signature at the very start of a file. For UTF-8 it is the three bytes EF BB BF. Those bytes are not part of your CSV columns; they are a hint that the rest of the file is UTF-8.

UTF-8 vs UTF-8 with BOM: same character encoding for the data; the only difference is whether those three hint bytes are present at the start. Some tools (including many Excel double-click opens on Windows) use the BOM as a strong signal to read the file as UTF-8. Other tools ignore the BOM or treat it as unwanted leading characters.

• Adding a BOM does not convert Windows-1252 or other legacy bytes into UTF-8.
• If the file is already wrong encoding, a BOM alone will not repair the text.
• A file that already has a UTF-8 BOM should keep a single BOM — do not stack another.

Why Excel sometimes misreads CSV encoding

When you double-click a .csv file, Excel often picks an encoding from regional defaults or a quick guess — not always UTF-8. If the file is UTF-8 without a BOM, Excel may treat multi-byte UTF-8 sequences as Windows-1252 (or another code page). The result is mojibake: garbled characters that look vaguely related to the original.

Opening via Data → From Text/CSV (or Get Data) usually lets you choose UTF-8 explicitly and is more reliable than double-click on many desktop Excel builds. Exact menu names differ by Excel year and platform. macOS Excel and Windows Excel do not always behave the same way for the same file.

Common symptoms

• Accented letters, names, or addresses look like Ã, Â, or random symbols.
• Text looks fine in a code editor or browser, but wrong in Excel after double-click.
• The first cell shows a weird character or the header looks shifted by one odd glyph (sometimes a visible BOM mishandling).
• Re-saving from Excel “fixes” display but corrupts the file for other UTF-8 tools (or the reverse).

Encoding problems vs delimiter / column problems

Do not treat every messy CSV open as an encoding issue.

• Encoding / BOM: individual characters inside cells are wrong (mojibake), but columns may still split correctly. Fixing encoding restores readable text without changing comma/semicolon layout.
• Delimiter / locale: whole columns merge or split wrong (one column where there should be five) because Excel expected ; and the file uses , (or the reverse). Characters may look fine.
• Both at once: possible, but diagnose separately — first confirm characters in a text editor, then check delimiter with a known header row.

If columns are wrong but every letter looks correct, a BOM or UTF-8 conversion will not fix the layout. If letters are garbled but columns look right, focus on encoding — not on changing separators.

Safe manual diagnosis

1. View the raw file outside Excel

1. Open the CSV in a plain text editor that can show encoding (VS Code, Notepad++, Sublime, etc.).
2. Confirm whether accented text already looks correct there. If it does, the file bytes are likely fine and Excel’s open path is the problem.
3. If text is already garbled in the editor, the export/source encoding may be wrong — a BOM will not repair it; you need a correct conversion from the real source encoding.

2. Check for a UTF-8 BOM

• In a hex view or “show special characters” mode, look for leading bytes EF BB BF.
• Editors often label the file “UTF-8 with BOM” vs “UTF-8”.
• Absence of a BOM does not mean the file is not UTF-8 — it only means there is no Excel-oriented hint at the start.

3. Retry Excel with an explicit UTF-8 import

1. Prefer Data → From Text/CSV (or equivalent) over double-click.
2. Set File Origin / encoding to UTF-8 (sometimes listed as 65001).
3. Confirm delimiter separately (comma vs semicolon) so you do not confuse encoding with locale.

Safe manual fixes

• Import with UTF-8 selected — often enough when the file is already valid UTF-8.
• Add a single UTF-8 BOM for recipients who will double-click on Windows Excel — only if the body is already valid UTF-8. Do not add a second BOM.
• Re-export from the source as UTF-8 (with or without BOM, depending on the consumer) instead of “fixing” a file that was saved in the wrong encoding.
• Explicit conversion from a known legacy encoding (for example Windows-1252) to UTF-8 — only when you know the source encoding. Guessing wrong makes mojibake worse.

When a BOM helps — and when it does not

• Helps: valid UTF-8 CSV without BOM; Excel double-click mis-guesses encoding; adding EF BB BF steers many Windows Excel opens toward UTF-8.
• Does not help: file is not UTF-8; wrong delimiter/locale; data already corrupted by a bad round-trip; consumer that rejects BOMs (some Unix pipelines and strict parsers).

Want the quick local fix?

If you prefer an offline browser tool that prepares a downloadable Excel-oriented copy without uploading your file, QuietForgeTools publishes:

The diagnosis and manual steps above remain useful on their own. Buying the tool is optional — use it when you want a local BOM/encoding prep step without hand-editing bytes. For a free read-only scan that reports BOM among other CSV issues, see the CSV Health Check.