Excel is the most common thing people open a CSV in — and the most common reason a CSV looks broken. The file is usually fine; Excel is just guessing. Here is every way it guesses wrong, and how to fix each one.
You open the CSV and all the data is crammed into column A, commas and all. This is a delimiter mismatch: Excel splits on whatever your operating system's list separator is, which is a comma in the US but a semicolon in many European locales. If the file's delimiter doesn't match, Excel never splits the columns.
Fix it with Data → From Text/CSV (Power Query), which lets you pick the delimiter explicitly, or select column A and use Data → Text to Columns. Better still, hand Excel a file whose delimiter it expects — convert to the delimiter your Excel wants, or skip the guessing entirely with a real workbook.
Order IDs, credit-card numbers, and other long digit strings get shown as scientific notation (1.23E+15) — and if you save, the precision is gone for good. Excel treats every all-digit field as a number and switches to scientific notation past 15 digits.
Import with Data → From Text/CSV and set the affected column's type to Text before loading. The durable fix is to open a real .xlsx where that column is already typed as text, so Excel has nothing to guess.
Zip codes, product codes and zero-padded IDs lose their leading zeros because Excel reads them as numbers. 00123 becomes 123; 07310 becomes 7310.
Same fix as scientific notation: import the column as Text via Data → From Text/CSV, or convert the CSV to an .xlsx with that column typed as text up front so the zeros survive.
03/04/2025 means March 4th to a US Excel and April 3rd to a UK one — and Excel will silently reinterpret your dates by its locale, sometimes turning a product code like 1-5 into a date too. There is no delimiter or encoding involved; it is pure locale guessing.
Keep dates in unambiguous ISO 8601 (2025-03-04) wherever you can, and when importing, set the column's date format explicitly in Data → From Text/CSV instead of letting Excel infer it.
Names like José show up as José, or you see a  stuck to the first header. That's a character-encoding mismatch: the file is UTF-8 but Excel opened it as Windows-1252, or a UTF-8 BOM confused it.
Open via Data → From Text/CSV and choose 65001: Unicode (UTF-8) as the file origin. If you control the export, save as UTF-8. Our full encoding fix guide covers this in depth.
Every symptom above is Excel inferring a type, a delimiter, or an encoding and getting it wrong. The way to end all of them at once is to give Excel a real .xlsx workbook with the cells already typed — numbers as numbers, IDs and zip codes as text, dates as dates. Then there is nothing left to guess.
You can do that here, in your browser — the file is never uploaded. Convert the CSV to a typed workbook and open it directly.
Almost always a locale difference. Excel uses your OS's list separator and date/number formats, so the same file splits and parses differently on a US vs European machine. The file itself is unchanged.
For inspecting and fixing delimiters or encoding, yes — a plain-text editor shows you exactly what's there. But for typed data (IDs, dates), a real .xlsx is safer because the types are explicit.
No. The conversion runs entirely in your browser with a self-hosted engine; the data never touches a server.
That's the European Excel default. Either open via Data → From Text/CSV and pick semicolon, or re-delimit the file to commas or tabs first.