creatorvalet
FilesConvert, compress and reshape files — without uploading them anywhere.MetadataSee what your files quietly carry, then strip exactly what you choose.Text & dataFormatters, converters, and the character-encoding fixes nobody else gets right.PublishingCheck how your pages read to crawlers, to people, and to language models.CodesBarcodes, QR and identifiers that keep working after you publish them.CharactersFind the character you can draw but cannot name — and the font you cannot place.

CSV UTF-8 vs CSV

Excel offers two CSV options and explains neither. The difference is three bytes at the start of the file — and whether your accented characters survive.

Updated 2026-08-04

Excel’s Save As dialog offers CSV UTF-8 (Comma delimited) and CSV (Comma delimited), one above the other, with no explanation of the difference.

The short answer: choose CSV UTF-8 unless you have a specific reason not to.

What the difference actually is

Both write the same rows in the same order. The difference is three bytes at the very start of the file, called a byte order mark, and which encoding the rest of the bytes use.

CSV UTF-8 writes those three bytes and encodes everything as UTF-8. The mark is a signal: any program reading the file sees it and knows to interpret the rest as UTF-8.

CSV writes no mark and encodes using your system’s legacy code page — Windows-1252 in Western Europe and North America. Any character outside that limited set is replaced with a question mark and is gone for good.

What goes wrong without it

Save a file containing Umeå as plain CSV on a system where the legacy code page does not cover it, and you get Ume?. That is data loss at save time, and no amount of care when opening the file will bring it back.

The more common failure is the opposite direction: a UTF-8 file without a mark, opened by Excel, which assumes the legacy encoding and renders å as Ã¥. The data is intact — the bytes are right — but every accented character displays wrong. This is recoverable, and a CSV viewer that detects it will show you the file is fine.

When plain CSV is right

Rarely, but it happens. Some older systems — particularly ones written in C without Unicode awareness, and some legacy import routines in accounting and payroll software — treat the byte order mark as part of the first column name. The result is a first header that looks correct but does not match anything, so the import fails or silently drops the column.

If an import keeps rejecting your file and the first column is the problem, the mark is a likely cause. That is the situation plain CSV is for.

The rule

Data going to a person, a modern system, or another spreadsheet: CSV UTF-8.

Data going into an old import routine that chokes on the first column: plain CSV, and confirm your data has no characters outside the legacy set before you trust it.

For more on why the encoding matters at all, see what a CSV file is.