Which should I pick, CSV or CSV UTF-8?

CSV UTF-8, unless the program you are sending the file to has told you it cannot read it. It keeps every character; plain CSV throws away any it cannot represent.

What is the ï»¿ at the start of my file?

The byte-order mark Excel writes in CSV UTF-8 files, shown by a program that does not expect it. It is three bytes before the first heading; most tools skip it, and the ones that do not show it as those three characters.

My accents show as Ã© — is the file broken?

No. That pattern means a UTF-8 file was read as Windows-1252; the bytes are correct and the reader guessed wrong. Open it here and the characters show correctly, and the download is clean UTF-8.

My accents show as question marks — can they be recovered?

Not from that file. A question mark written into a CSV means the character was dropped at save time. Go back to the source and export as CSV UTF-8.

Does the delimiter fixer change my numbers or dates?

Only if you leave "Convert decimal commas" ticked, which turns 1.234,56 into 1234.56 in columns that are almost entirely numbers. Untick it and every value is carried through as text; dates are never touched either way.

Is my file uploaded anywhere?

No. Whether your file is UTF-8 or Windows-1252 is decided in this page from the bytes themselves, and the clean UTF-8 copy is written on your machine too. The browser is told to block outbound connections throughout.

All guides

CSV UTF-8 or plain CSV — which one to save from Excel, and why the accents break

Plain "CSV" from Excel is written in the character set of the computer that saved it — Windows-1252 on most English and Western European machines — so any character outside it, from a Polish ł to a rupee sign, is replaced by a question mark and lost. "CSV UTF-8" writes every character, plus a three-byte marker at the start that some programs show as ï»¿. Save as CSV UTF-8 unless the program receiving the file refuses it.

What each option writes

CSV UTF-8 (Comma delimited) encodes every character the way the web does, so a file with names in Greek, Hindi and Vietnamese round-trips intact. Excel also puts a byte-order mark at the front — three bytes that tell the next program the file is UTF-8 — which is why some tools show ï»¿ glued to the first heading, and why a heading called id can fail to match "id" in a script.

CSV (Comma delimited) uses the legacy character set of your Windows locale. Characters it can represent survive; characters it cannot become a question mark in the file itself, and there is no undo for that. For a file of plain English letters, digits and punctuation the two differ only in that marker, which is why the choice goes unnoticed until a name has an accent in it.

Reading a file that came out wrong

Two different symptoms, two different causes. Pairs like Ã© where é should be, or â€™ where an apostrophe should be, mean the file is UTF-8 and was read as Windows-1252: the data is fine and the reader chose wrong. Question marks or empty boxes where the characters should be mean the file was written without them, and the original export is the only place they still exist.

For the first case, the delimiter fixer here reads the file, detects which encoding it is in and says so, and writes it out as clean UTF-8 with the separator you choose. Untick "Convert decimal commas" if all you want is the encoding fixed: with it on, the fixer also rewrites 1.234,56 as 1234.56 in columns that are almost entirely numbers. For the second, no tool can invent the characters back; re-export as CSV UTF-8 from the source.

When the other side wants plain CSV

Some older systems reject the byte-order mark, and a few insist on their own legacy character set. If the data is plain English, plain CSV writes the same bytes without the marker, and is the safe choice for a program that rejects it. If it is not, the file cannot be both faithful and in a character set that lacks the characters; ask the receiving system which UTF-8 it accepts, with or without the marker, before choosing loss.

The health check here reports the encoding it found, so you can see which kind of file you have before sending it anywhere.

Questions

Which should I pick, CSV or CSV UTF-8?: CSV UTF-8, unless the program you are sending the file to has told you it cannot read it. It keeps every character; plain CSV throws away any it cannot represent.
What is the ï»¿ at the start of my file?: The byte-order mark Excel writes in CSV UTF-8 files, shown by a program that does not expect it. It is three bytes before the first heading; most tools skip it, and the ones that do not show it as those three characters.
My accents show as Ã© — is the file broken?: No. That pattern means a UTF-8 file was read as Windows-1252; the bytes are correct and the reader guessed wrong. Open it here and the characters show correctly, and the download is clean UTF-8.
My accents show as question marks — can they be recovered?: Not from that file. A question mark written into a CSV means the character was dropped at save time. Go back to the source and export as CSV UTF-8.
Does the delimiter fixer change my numbers or dates?: Only if you leave "Convert decimal commas" ticked, which turns 1.234,56 into 1234.56 in columns that are almost entirely numbers. Untick it and every value is carried through as text; dates are never touched either way.
Is my file uploaded anywhere?: No. Whether your file is UTF-8 or Windows-1252 is decided in this page from the bytes themselves, and the clean UTF-8 copy is written on your machine too. The browser is told to block outbound connections throughout.