Guide
CSV UTF-8 vs CSV in Excel: Which One to Save As
Published
Save As in Excel offers four kinds of CSV: CSV UTF-8 (Comma delimited), CSV (Comma delimited), CSV (Macintosh) and CSV (MS-DOS). The names do not tell you what changes between them, and picking the wrong one can quietly replace characters in your data with question marks.
The short answer: choose CSV UTF-8, unless the program that will read the file specifically asks for ANSI or Windows-1252. The rest of this guide shows why, using the actual bytes each format wrote.
The Test
We typed a small table into Excel 2021 on a US-English Windows 11 PC and saved it once in each format. The names were chosen to test character sets: Zoë and Kraków use accented Latin letters, Tōkyō uses a letter that older Western character sets lack, 田中 is Japanese, and “quoted” uses curly quotation marks. A second sheet held one more line of text.
What Each Format Wrote
| Format | Character set | BOM | Zoë, Kraków | Tōkyō | 田中 | “quoted” | Lines end with |
|---|---|---|---|---|---|---|---|
| CSV UTF-8 (Comma delimited) | UTF-8 | Yes | Kept | Kept | Kept | Kept | CR LF |
| CSV (Comma delimited) | Windows-1252 | No | Kept | T?ky? | ?? | Kept | CR LF |
| CSV (Macintosh) | Mac Roman | No | Kept | T?ky? | ?? | Kept | CR |
| CSV (MS-DOS) | Code page 437 | No | Kept | T?ky? | ?? | ?quoted? | CR LF |
Three things in that table matter more than the rest.
The question marks are in the file. They are not a display problem that a different program or a different encoding setting could fix. Excel had no byte for ō or 田 in those character sets, so it wrote the byte for ? instead. Once saved that way, the original letters exist only in your workbook.
“Kept” does not mean the bytes are the same. All four formats kept Zoë, but each wrote the ë as a different byte: C3 AB in UTF-8, EB in Windows-1252, 91 in Mac Roman and 89 in code page 437. A program that expects UTF-8 and receives any of the other three shows the letter as a garbled symbol, which is where most encoding problems begin.
CSV (Macintosh) is for the old Mac OS, not today’s Mac. It separates lines with a lone carriage return and uses Mac Roman, the character set of the classic Mac OS, so a current program expecting UTF-8 garbles its accents just as it would a Windows-1252 file. CSV (MS-DOS) is a similar leftover, for programs that expect the character set of DOS.
On the PC we tested, CSV (Comma delimited) used Windows-1252, the Western European set. We did not test a PC set to another language, and there it may use that language’s older character set instead, so check the bytes before you rely on it.
Why the BOM Matters
A CSV file has nowhere to record its character set, so a program opening it has to guess. The byte order mark, three bytes at the very start of a UTF-8 file, is the hint Excel looks for. We opened the same UTF-8 file in Excel twice:
| File | What Excel showed |
|---|---|
| UTF-8 with a BOM | Zoë, Kraków |
| UTF-8 without a BOM | Zoë, Kraków |
That is why CSV UTF-8 is the format that survives a round trip through Excel: it writes the BOM, and Excel reads it back. It is also why a UTF-8 export from a web app, which usually has no BOM, looks garbled when you double-click it — the file is fine, and the encoding fixer adds the missing BOM without changing anything else.
The BOM has one cost. A program that does not expect it reads those three bytes as part of the first column name. Python’s csv module, reading with encoding="utf-8", returned the first header as name, so a lookup for name fails. Reading with encoding="utf-8-sig" returned name. Most tools handle it; when one does not, the symptom is always a first column that cannot be found by name.
What Both Formats Save: What You See, Not What Is Stored
The choice of format changes the character set, not the values. Both CSV UTF-8 and CSV (Comma delimited) wrote each cell exactly as its number format displays it, and nothing more:
| In the cell | Number format | Written to the CSV |
|---|---|---|
| 4111111111111111 | General | 4.11111E+15 |
| 2.34567 | Two decimal places | 2.35 |
| 1 March 2026 | dd/mm/yyyy | 01/03/2026 |
| 00742 | Text | 00742 |
=2+3 | General | 5 |
The long number is the one that hurts: the file holds 4.11111E+15, and the other ten digits are gone for good. Column width made no difference: in a narrow column the cell showed 4.11E+15, yet the file received the General format’s longer version. Format ID and card-number columns as Text before you save, and see stopping Excel turning long numbers into 4.5E+15 for the full fix. Formulas are saved as their results, and only the active sheet is saved at all: text on our second sheet appeared in none of the four files.
Which Format to Choose
| The file is going to… | Save as |
|---|---|
| Be opened in Excel again, by you or anyone else | CSV UTF-8 |
| Be imported into a web app, database or online store | CSV UTF-8 |
| Be read by a script | CSV UTF-8, read with utf-8-sig in Python |
| An older program whose documentation says ANSI or Windows-1252 | CSV (Comma delimited), after checking for characters it cannot hold |
| A DOS-era or classic Mac OS program | CSV (MS-DOS) or CSV (Macintosh) |
A quick test tells you whether an older program needs the non-UTF-8 format: import a CSV UTF-8 file containing Café. If it shows Café, the program is reading Windows-1252. Save as CSV (Comma delimited) for that program only, and keep a CSV UTF-8 copy as your master.
Fixing a File Saved in the Wrong Format
It depends on which way it went wrong. If a Windows-1252 file shows garbled accents in a program that expects UTF-8, nothing is lost: the encoding fixer detects Windows-1252 and converts the file to UTF-8, with or without a BOM, on your own computer. If the file already contains question marks where letters used to be, no converter can help. Go back to the workbook, or to the original export, and save it as CSV UTF-8.