Why your CSV opens as gibberish in Excel

You export a customer list. You open it in Excel. The Arabic names are a wall of Ø and Ù, every row is crammed into column A, and the customer IDs have lost their leading zeros.

Three separate faults. One cause: a CSV file contains no statement of what it is. Not the character encoding, not the delimiter, not the type of any column. Every reader has to guess, and Excel guesses using rules that made sense in 1995.

Fault one: the encoding

Your file is UTF-8, the encoding essentially everything has used for twenty years. Excel opens it assuming your system's regional code page — Windows-1256 for Arabic, Windows-1252 for Western European.

The bytes are correct. The table used to read them is not. An Arabic letter is two bytes in UTF-8, and read one byte at a time through Windows-1252 those bytes are Ø and something else. Hence أحمد becoming أحمد.

The fix is three invisible bytes at the start of the file. A UTF-8 byte-order mark — EF BB BF — tells Excel the file is UTF-8 and it stops guessing. Every tool on this site that exports CSV writes one.

If you already have a broken file, the repair is reversible: nothing was lost, the bytes were merely misread, so re-reading them correctly recovers the text.

Fault two: the delimiter

Your file is comma-separated. Excel on a European or Middle Eastern system expects semicolons, so it finds no delimiter at all and puts each entire line into one cell.

This is not a bug. In locales where the comma is the decimal separator — 3,14 rather than 3.14 — a comma cannot also separate fields, so those Excel installations use a semicolon and call it the “list separator”. The same file is correct on one machine and unreadable on the next.

There is no delimiter that works everywhere. You can match the recipient's locale, use tab-separated values, or import through Excel's Data tab where the delimiter can be stated explicitly. All three require knowing something about the other end.

Fault three: Excel changing your data

This is the one that does lasting damage, because the file opens looking fine.

Excel decides what each column contains by looking at it, and it is confident:

• 00123 becomes 123. Leading zeros are not significant in a number, so the product code is now a different product code.
• +962 79 555 1234 becomes something else entirely, or an error, because it begins with a plus sign.
• 1-2 becomes a date. So does 3/4. So, famously, do certain gene names — which is why the genetics community renamed several genes in 2020 rather than keep fighting the spreadsheet.
• A long number becomes scientific notation, and beyond fifteen digits the last digits become zeros. Credit card and IBAN numbers are longer than fifteen digits.

None of this is reversible by closing without saving if you already saved. The original values are gone, and the file still looks like a valid spreadsheet.

What actually fixes it

Use .xlsx instead of CSV. This solves all three faults at once. The format declares its own encoding, has no delimiter, and stores each cell's type explicitly. A customer ID written as text stays text.

Converting CSV to a real workbook takes a few seconds and removes the entire category of problem. If you control the export, export .xlsx.

If it must be CSV: write a byte-order mark, match the recipient's delimiter, and tell them to import via Data → From Text rather than double-clicking, so the columns can be marked as text.

If you are receiving rather than sending: open Excel first, then use Data → From Text/CSV. That dialogue lets you set the encoding and the delimiter and mark columns as text before anything is parsed. Double-clicking the file skips all of it.

Why not just fix Excel?

Fair question. The behaviour is decades old and changing it would break an enormous amount of existing work — every file that currently opens correctly would need to keep doing so. Microsoft has added a “do not convert” option in recent versions, but the defaults remain what they were.

In practice the answer is not to fight it. CSV was never a specification; it was a convention that became a de facto standard without acquiring the metadata a format needs. Where the data matters, use a format that describes itself.

The short version

Gibberish text means the encoding was guessed wrong — add a byte-order mark. Everything in one column means the delimiter was guessed wrong — match the recipient's locale. Missing leading zeros and dates where you had text mean Excel decided your data's types for you — and that one you cannot undo.

All three disappear if you send an .xlsx file instead.