The UTF-8 BOM: Why Excel Sometimes Needs It in a CSV

## Why it matters

If your table has accented characters like é, ñ, ü or symbols like °, €, or ¥, and you're exporting to CSV to open in Excel, the BOM becomes important. Without it, Excel might misguess the file's encoding and turn those characters into gibberish (mojibake). With the BOM, Excel recognises the file as UTF-8 from the first three bytes and renders the accents correctly.

The BOM is a safety net for an encoding-detection problem. It's not required by the UTF-8 standard; it's an Excel compatibility quirk. But it's a useful one if your data travels through Windows tools.

## How it works

The byte-order mark is literally the first three bytes of the file: EF, BB, BF in hexadecimal. Those bytes don't represent any text character; they're a marker. When Excel double-clicks a CSV file to open it, the file parser checks for those three bytes. If they're there, it knows to read the rest as UTF-8. If they're missing, it guesses based on the system locale, and sometimes guesses wrong.

UTF-8 doesn't theoretically need a BOM because the encoding scheme itself is unambiguous. Every character maps to a specific byte sequence. But UTF-16 (which stores each character in two bytes) does need a BOM to know whether the bytes are in big-endian or little-endian order. Excel's CSV import logic was built with support for both encodings, so it treats a BOM as a helpful signal when it exists.

Once Scalpel exports the CSV, the BOM sits in the file forever. It doesn't affect the data; it's metadata about encoding. If you open the file in a text editor, you won't see it, but it's there at the byte level.

## What does not matter

The BOM doesn't change the actual characters or the data. Every cell in the table is identical whether the BOM is there or not. The only difference is how tools interpret the bytes.

Some tools actively dislike the BOM. Older Python csv modules treat the BOM as part of the first field. Some import tools in analytics platforms or programming libraries treat it the same way. For a file you're piping into a Python script or uploading to a data pipeline, the BOM might cause a tiny headache (an extra invisible character in the first cell).

The toggle lets you choose. Leave it on if you're opening the file in Excel. Turn it off if the file is heading into a script or a web uploader that parses CSV strictly.

## Code example

The same table with and without a BOM:

Without a BOM (UTF-8 only):

Product,Price
Dresses,€49.99
Shirts,¥3,500
Copy

Opened in Excel on some Windows systems, this might render as:

Product,Price
Dresses,?49.99
Shirts,¥3,500
Copy

The euro symbol becomes a question mark because Excel guessed the wrong encoding.

With a BOM (the three bytes EF BB BF at the start):

[BOM]Product,Price
Dresses,€49.99
Shirts,¥3,500
Copy

Excel sees the BOM, recognises UTF-8, and renders both symbols correctly.

In a hex dump, the BOM looks like:

EF BB BF 50 72 6F 64 75 63 74 2C 50 72 69 63 65 ...
Copy

The EF BB BF are the BOM bytes; the rest is the text Product,Price in UTF-8.

## How Scalpel shows it

The "UTF-8 BOM" toggle sits in the table card's footer, alongside the escape-formulas toggle. The default is on. Turn it off and Scalpel strips the BOM from every CSV export. Turn it on and Scalpel includes it.

The toggle applies to CSV downloads and to pastes of CSV text. It doesn't affect XLSX, Markdown, or TSV formats (XLSX has its own encoding rules; TSV and Markdown don't use BOMs).

If you're working with a mix of tools, the choice is usually clear: Excel users leave it on; automation and scripts leave it off.