Why Your CSV Breaks Accents and Dates in Excel

Three faults, one complaint

The sentence people write is always the same: the CSV is broken. What they mean is one of three different things, and the three have nothing in common except the file extension. The accents are wrong, which is an encoding problem. Everything is in the first column, which is a separator problem. The values are right but the wrong shape — 03/04 has become a date, a postcode has lost its zero, a long reference has turned into something with an E in it — which is neither, and which happens after the file has been read correctly.

Telling them apart takes one action: open the CSV in a plain text editor rather than a spreadsheet. Notepad, TextEdit, gedit, anything that shows you the bytes as text and does not try to be helpful. In that window there are no columns, no cells and no types — just lines with characters between the fields. If the accents look right there, the file is correct and the fault is entirely in how Excel is reading it. If they look wrong there too, the fault is upstream, in whatever wrote the file, and no import setting will repair it.

The accents: three missing bytes at the front of the file

In UTF-8, a plain unaccented letter takes one byte and an accented one takes two. That is the whole of the mechanism. When a program reads a UTF-8 file but believes it to be in a legacy single-byte code page, it shows each of those two bytes as its own character, and the mangling that results is completely deterministic. A lone é becomes é. The word naïve becomes naïve and résumé becomes résumé. Every accented letter grows by exactly one character, and the first of the pair is almost always à or Ã, which is why the wreckage has such a recognisable look.

The remedy that the whole industry converged on is three bytes at the very front of the file: EF BB BF, the UTF-8 byte order mark. It encodes no character and prints nothing; it exists purely so that a reader can tell what it is looking at. Microsoft's own page on the subject says it in one line — a UTF-8 CSV opens normally if it was saved with a byte order mark — and offers an import route for files that lack one. That single sentence explains why almost every export button you have ever pressed produces a file that starts with three invisible bytes.

The converter on this site does not add one. The CSV it hands you is UTF-8 with no byte order mark, and the first byte of the file is the first character of your first column heading. That is the correct thing to produce by the standard — RFC 4180 defines the format and never mentions a mark — and the wrong thing to double-click on a European Windows machine. The rest of this article is largely about what to do with that fact, and the short version is that you import the file instead of opening it.

The separator: your operating system decides, not the file

The name comma-separated values suggests the comma is part of the format, and RFC 4180 does define it that way. Excel does not read the format; it reads a setting. Microsoft's own troubleshooting page states it without hedging: changing the list separator in the Windows region settings affects the delimiter used when opening or saving a comma-separated value file, because Excel uses the Windows list separator character as the delimiter for .csv files. It adds that the comma is the default list separator for the US-English locale.

The reason the setting is not a comma everywhere is arithmetic, not preference. Where the decimal mark is a comma, a comma cannot also separate fields without ambiguity: a row containing a price of one thousand two hundred and thirty-four point five would be indistinguishable from two fields. Windows therefore ships a semicolon as the list separator across the French, German, Spanish, Italian and Portuguese locales, and a comma in the English ones. That is the whole of the continental divide, and it is why an export written by an American service and opened in Lyon, Leipzig, León, Livorno or Lisbon arrives as one very wide column.

Two things follow that people get wrong. The first is that changing the Windows list separator to fix one file is a global change affecting every application on the machine, and Microsoft's own documentation warns as much; it is not a per-file remedy and you will forget you did it. The second is that the delimiter is a property of the file and the setting is a property of the reader, so a file is never right or wrong in the abstract — it is right for a reader you have told the truth to. The import dialogue exists precisely to let you tell it.

The typing: Excel guesses, and it guesses while it opens

A CSV has no types. Every field is text, and RFC 4180 gives quotes exactly one job: protecting a field that contains a comma, a quote or a line break. There is nowhere in the format to say this is a string, leave it alone. So a spreadsheet opening one has to guess, field by field, and the guesses are made to suit the common case rather than yours. A field reading 03/04 looks like a date and becomes one. A field reading 01234 looks like a number and loses its zero. A field with sixteen digits looks like a very large number, and Microsoft's own page states the limit without softening it: Excel has a maximum precision of 15 significant digits, so for any number of 16 or more digits, everything past the fifteenth is rounded to zero, and the value is displayed in scientific notation.

The date case deserves a paragraph of its own because of how it fails. A field reading 02/03/2026 is 2 March in Paris and 3 February in Chicago, and both readings are legitimate — nothing in the file says which was meant. But a field reading 13/03/2026 has no thirteenth month, so a reader expecting month-first cannot parse it as a date and leaves it as text. Run a full year of dates through and roughly two in five are ambiguous: 144 of the 365 days fall on the twelfth of the month or earlier. The column that comes out is therefore part silently-swapped dates, part left-aligned text, and no error message anywhere. It is the most expensive quiet failure in office work.

Some of the damage happens before Excel is even involved, and this converter is not innocent of it. A spreadsheet cell is a raw value plus a display format, and the CSV can only carry one of the two, so what gets written is the formatted text. Run the same 2 March 2026 through with a day-first format applied and the file gets 02/03/2026; run the identical value with a month-first format and the file gets 3/2/26. Worse, a sixteen-digit identifier sitting in a general-format column comes out of the workbook already written as 1.23457E+15, because that is how the workbook was displaying it. The identifier was destroyed by the format, not by the reader. Nothing downstream can recover it.

What actually fixes each one

Import instead of open. That single change addresses the first two problems outright and gives you the tool to address the third. Data, then From Text/CSV, brings up a preview with the file origin and the delimiter both visible and both changeable, and the preview redraws as you change them, so you can see the accents come right and the columns split before you commit. Choosing Transform Data instead of Load then lets you set a column's data type to Text — Microsoft's own guidance on keeping leading zeros points at exactly this route — and a column typed as Text keeps its zeros, keeps all sixteen of its digits and does not become a date.

There is a newer and more permanent lever that far too few people know about. On Microsoft 365 and Excel 2024, both Windows and Mac, File, Options, Data contains a section called Automatic Data Conversion with four checkboxes: remove leading zeros and convert to number; keep the first 15 digits of long numbers and display in scientific notation if required; convert digits surrounding the letter E into scientific notation; and convert date-like combinations of letters and numbers into a date. Turning the first two off is the single highest-value ten seconds anyone who handles reference data can spend in Excel, because it stops the destruction at the source instead of asking you to remember an import ritual every time.

What does not work is worth listing too, because these are the suggestions you will be given. Wrapping a field in quotes does not stop the conversion: quotes are structural, they say where the field ends, and Excel strips them before it starts guessing. Renaming the file so it is no longer a .csv changes which code path opens it, which is a real effect but a fragile one to rely on. Formatting the column as Text after the file is already open does nothing, because the digits were lost during the load and Microsoft says as much — a text format only affects what you enter afterwards. And putting an equals sign in front of a quoted value does force text, but it makes the field a formula rather than a value, it renders as literal characters in every other program that reads the file, and a leading equals sign is the classic vector for spreadsheet formula injection. Do not send that to anyone.

What this converter puts in the file

Read out of the source rather than the marketing: the Excel to CSV tool reads your workbook in the browser, lets you pick a sheet, and writes that sheet with a comma between fields, UTF-8 encoding and no byte order mark. Fields are quoted only when they need to be — when they contain a comma, a double quote or a line break — which is exactly what RFC 4180 requires and nothing more. A field containing a quote has that quote doubled, per the same rule. Nothing is uploaded; the workbook is parsed on your machine and the CSV never leaves it.

Two of those choices will bite a European reader who double-clicks the result, and you should know which. The comma will put everything in column A on a machine whose list separator is a semicolon. The missing byte order mark will mangle the accents on a machine that falls back to a legacy code page. Both are cured by the same import procedure and neither is cured by complaining about the file, which is standards-correct. If you are sending the CSV to a person rather than to a program, say which separator and which encoding you used — one line in the email saves an afternoon.

One habit is worth more than every setting in this article: fix the workbook before you export it, not the CSV after. Set the identifier columns to Text in the spreadsheet, so the postcodes and account numbers are already strings when the conversion happens. Set the date columns to an unambiguous format — the year first, four digits, then month, then day — so the exported text cannot be read two ways in any locale on earth. Do that once, and every export from that workbook is clean for every reader, forever, whatever their regional settings happen to be.

Frequently asked questions

I opened the file and every row is in column A. Is the CSV broken?

Almost certainly not. What you are seeing is Excel splitting on a character your file does not use. Microsoft documents that Excel takes the delimiter for .csv files from the Windows list separator, so a comma-separated file on a machine set to a semicolon finds no semicolons and concludes that each line is one enormous field. Open the file in a text editor and look at the first line: whichever character sits between the headings is the real delimiter. Then close it, go to Data and From Text/CSV, and choose that character in the preview. Two things not to do: do not split the column by hand, because you will do it again next month; and think twice before changing the Windows list separator, since Microsoft's own documentation warns that it is a global change affecting every application on the machine.

Why doesn't putting quotes around a field stop Excel turning it into a date?

Because quotes in a CSV are punctuation, not annotation. RFC 4180 gives them exactly one job: marking where a field starts and stops when the field itself contains a comma, a double quote or a line break. They carry no information about what the field means, and there is nowhere else in the format to put such information — a CSV genuinely has no concept of a type. So the reader strips the quotes as part of parsing, exactly as it is supposed to, and only then starts guessing what it is holding. This is why every remedy Microsoft publishes is on the reading side rather than the writing side: import the column as Text, or switch the automatic conversions off. Nothing you can write into the file itself will constrain the guess.

Should I just put sep=; on the first line so Excel gets it right?

It works in Excel, and it is a trap everywhere else. That first line is an Excel-specific extension: RFC 4180, which defines the CSV format, does not mention it and no conforming parser is required to understand it. So the file becomes easier for one program and harder for every other one — a script, a database import, an accounting package or a colleague on a Mac will read that line as a data row containing a field called sep=; and either fail or silently import a junk record at the top of your table. If the file is going to a human who will open it in Excel and nowhere else, it is a reasonable convenience. If it is going into a pipeline, or to someone whose tools you do not know, do not put it there — send the file clean and say in one sentence which separator and which encoding you used.

My 16-digit reference number now ends in zeros. Where did the digits go?

They were rounded away, and they are not recoverable from that file. Microsoft states the rule directly: Excel has a maximum precision of 15 significant digits, and for any number of 16 or more digits everything past the fifteenth is rounded down to zero. The value is then displayed in scientific notation because it no longer fits the column meaningfully. The important part is that this is not a display problem — widening the column or changing the number format will not bring the digits back, because they are gone from the stored value. Go back to the original source, import the column as Text, and never let a reference number, an account number, a card number or a long product code exist as a number anywhere in the chain. On Microsoft 365 and Excel 2024 you can also turn the conversion off outright: File, Options, Data, and clear the option about keeping the first 15 digits of long numbers.

Comma or semicolon — which one is actually correct?

By the standard, the comma. RFC 4180 defines the format with commas between fields, a carriage return and line feed at the end of each record, and double quotes around any field that contains one of those. Every programming language, database and data tool follows it, so a comma is what to use for anything a machine will read. In practice, though, the semicolon is what a spreadsheet expects across most of continental Europe, for the arithmetic reason that a comma is already the decimal mark there. The workable rule is to decide by destination rather than by principle: comma for machines and for anything crossing a border, semicolon when the file is going straight into a colleague's Excel and you know their regional settings. And whichever you choose, say so — one line stating the separator and the encoding prevents the entire class of problem this article is about.