CSV UTF-8 vs CSV in Excel: Which One to Save As

CSV UTF-8 (Comma delimited) is a plain-text table, one row per line with commas between the values, saved in UTF-8 with a byte order mark at the start of the file. CSV (Comma delimited) is the same layout saved in an older Windows character set, or code page, instead: Windows-1252 on the US-English PC we tested. Of Excel’s four CSV formats, CSV UTF-8 is the only one that writes every character a sheet can hold, and the only one that writes the byte order mark Excel needs to read those characters back. The other three — CSV (Comma delimited), CSV (Macintosh) and CSV (MS-DOS) — replace any character their older character set lacks with a question mark, in the file itself, where no later conversion can undo it.

The names in the Save As list say none of that, which is why picking one at random loses data without warning. Even “Comma delimited” is loose: Excel separates the values with the list separator from your Windows regional settings, a comma on our PC but usually a semicolon where a comma is the decimal mark. A file already saved as CSV (Comma delimited) with no letters turned into question marks, or as UTF-8 without the byte order mark, needs no trip back to Excel: convert it to UTF-8 with a BOM in your browser. The rest of this guide shows what each format actually wrote, byte by byte, and what any CSV leaves behind that an XLSX or ODS workbook keeps.

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

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:

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 RowSlice’s CSV to UTF-8 converter adds the missing BOM without changing any of the values.

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:

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 scientific notation for the full fix.

CSV UTF-8 vs XLSX vs ODS: What Each One Keeps

Any CSV, UTF-8 or not, holds one sheet of values and nothing else. XLSX, Excel’s own workbook format, and ODS, the OpenDocument format LibreOffice uses, hold the whole workbook. We saved a second test workbook as CSV UTF-8, XLSX and ODS from the same Excel, opened each file in Excel again and read the files themselves:

When you save as CSV, Excel warns that only the active sheet will be kept and that some features may be lost; the table shows which. Only CSV makes you choose a character set: XLSX and ODS always store text as Unicode (UTF-8 in the files we saved), so any character a cell can hold survives. ODS kept everything in our small test, though Microsoft notes that some Excel features and formatting have no OpenDocument equivalent. Going the other way, RowSlice’s CSV to Excel converter builds an .xlsx from the CSV’s text, so 00742 arrives as 00742 rather than 742.

So the choice follows where the file goes next. Keep working in XLSX while the data is still being edited in Excel, or in ODS if it will be edited in LibreOffice Calc or OpenOffice. Save a CSV, UTF-8 unless the receiving program says otherwise, only for the copy you hand to another system: an import, a database, a script. Keep the workbook as the master, because a CSV cannot give back what it never stored.

Which Format to Choose

When the file has to be a CSV, pick the format by what will read it:

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 use CSV UTF-8 everywhere else.

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: convert the CSV to UTF-8 with RowSlice, which detects Windows-1252 and writes 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.