UTF-8, BOM and Excel: Why Your CSV Shows  or Broken Accents

Updated July 24, 2026 · By the CSVUndo team · 6 min read · Applies to Excel 2016–365 on Windows and Mac

Two very different complaints, one cause. Either your database rejects an import because the first column is apparently named order_id, or Excel opens an export and every café on the menu has become café. Both problems trace back to the same three bytes at the very start of the file: the UTF-8 byte order mark, or BOM.

Whether those bytes should be there depends entirely on who reads the file next. This guide explains what the BOM is, why Excel needs it, why almost everything else would rather not see it, and how to add or strip it in seconds.

Two symptoms, one cause

Symptom 1:  appears at the start of the file

You see  stuck to the first header in an older text editor, a legacy ETL tool, or an error message like PostgreSQL's ERROR: column "id" does not exist. Nothing is wrong with your data. The file begins with a BOM — the bytes EF BB BF — and the program reading it is not decoding UTF-8. Run those three bytes through the Windows-1252 character table one at a time and you get exactly ï, », ¿. The gibberish is the BOM, seen through the wrong lens.

Symptom 2: accents break when Excel opens the file

The mirror image. The file is genuine UTF-8 but carries no BOM, and someone double-clicks it. With no BOM to check, Excel assumes the machine's ANSI code page — Windows-1252 on most US and Western European PCs. UTF-8 stores é as two bytes, C3 A9; decoded as Windows-1252 those bytes render as é, so Müller becomes Müller and François becomes François. We map the whole substitution pattern in our é instead of é guide.

Same three bytes both times: present when the reader did not want them, or absent when Excel needed them.

What a BOM actually is

The byte order mark is the Unicode character U+FEFF placed before the first real character of a file. It earned its name in UTF-16, where it genuinely signals byte order. UTF-8 has no byte-order question to settle, so there the BOM is purely a signature — three fixed bytes, EF BB BF, that announce “this file is UTF-8.” A program that decodes the file correctly consumes it silently; you will never see it in Excel, VS Code, or a browser. It only becomes visible when something reads the raw bytes with the wrong decoder:

First bytes on disk       Read as UTF-8      Read as Windows-1252
EF BB BF                  (invisible)        
EF BB BF 69 64            id                 id

That second row is why database imports fail: the BOM glues itself onto the first header, and a column named id is suddenly named U+FEFF + id — identical on screen, different to every string comparison.

The Excel rule of thumb

When you double-click a CSV, the BOM is the only encoding evidence Excel consults. Found: the file is decoded as UTF-8 and every accent survives. Not found: Excel silently assumes ANSI, and symptom 2 strikes. This is why Excel's own Save As → CSV UTF-8 (Comma delimited) format, added in Excel 2016, always writes a BOM — Microsoft knows its own reader needs one.

Most machine consumers take the opposite view. The UTF-8 standard says the BOM is optional and discouraged, and a long list of tools treats those three bytes as data: PostgreSQL's COPY, MySQL's LOAD DATA INFILE, many JSON and API pipelines, Python's plain utf-8 codec, and Unix tools like grep and diff, where a match against the first line quietly fails.

How CSVUndo handles it

Every CSVUndo tool puts the choice on the export step as a single checkbox: Add UTF-8 BOM (for Excel). Leave it checked when the file is headed for someone's inbox and a double-click; uncheck it when the file feeds a database, an API, or a script. Same repaired data either way — only the first three bytes differ.

One important distinction: the checkbox controls future encoding detection, but it cannot un-mangle text that was already decoded wrongly and saved. If your file permanently contains café, run it through the broken characters fixer first — it reverses the common mojibake substitutions — then export with the BOM setting your destination needs.

The sep=; conflict

European Excel setups often lean on another first-line trick: putting sep=; on line 1 forces Excel to split on semicolons when the file is double-clicked. Here is the catch almost nobody documents: Excel only honors sep= when those characters are the very first bytes of the file. Put a BOM in front of it and the directive is ignored — Excel decodes your accents correctly and then dumps every row into column A. You get one or the other, never both.

If a semicolon-delimited file is landing in a single column right now, our all-data-in-one-column guide walks through the fixes. For files you generate yourself, the cleanest escape is to skip the conflict entirely: use comma delimiters with a BOM for Excel-bound files, or drop both tricks and import through Data → From Text/CSV, where the delimiter and the encoding are each set explicitly.

Frequently asked questions