CSV to Excel and Back Without Breaking Your Data

The separator problem starts before the file is even opened

Excel decides how to split a CSV into columns using the list separator configured in your operating system's regional settings, not by looking at the file. On a machine set to a European locale, that separator is a semicolon by default, so an ordinary comma-separated export lands in a single column of unsplit text. On a US-configured machine, the reverse happens to a semicolon file. Neither result means the file is broken. It means Excel guessed from settings that have nothing to do with how the file was written. A converter such as CSV to Excel that parses the file with several candidate separators and checks which one produces a consistent field count across the sampled lines sidesteps the guess entirely, instead of trusting either the file extension or a system setting.

Leading zeros and long numbers are the quiet casualties

The most damaging thing that can happen during a CSV-to-Excel conversion is being too eager about turning text into numbers. A product code written as 00123 becomes the number 123 the instant a spreadsheet decides it looks numeric, and that leading zero is not recoverable afterwards. It is simply gone. Longer identifiers fail differently. A sixteen-digit card or barcode number loses its last few digits without any warning, because standard spreadsheet numbers cannot hold more than about fifteen significant figures without rounding. Both of these should stay as text rather than being converted, and the same rule applies when the destination is a program rather than Excel: CSV to JSON keeps them as strings. Values that really are numbers, such as quantities, prices and totals, should still convert normally so they can be summed and calculated on.

Encoding is where non-English data breaks

Files exported from older accounting systems or databases are frequently not UTF-8 at all. Windows-1251 for Cyrillic text and Windows-1252 for Western European accented characters are the common cases, and opening one under the wrong assumption produces the familiar wall of garbled characters. Detecting the real encoding by checking for a byte order mark first, then validating strictly as UTF-8, and falling back based on the distribution of high bytes if that fails, catches this automatically. Nobody has to guess at a menu of encoding options.

The byte order mark itself can cause its own quiet damage

A UTF-8 byte order mark is three invisible bytes at the very start of a file that tell Excel the text that follows is Unicode. That is useful when Excel is the destination. It becomes a problem the moment the file's destination is something other than Excel. A command-line tool or an older data pipeline that doesn't strip those bytes ends up with them glued onto the first character of the first header cell, so a column meant to be called "id" no longer matches anything expecting that exact name. Whether the BOM should be kept or dropped depends entirely on what reads the file next, not on a single universal default.

Going the other direction has its own decisions to make

Converting a spreadsheet back to CSV with Excel to CSV raises a question that going the other way never does. A cell holding a formula has two values, the formula text itself and the number it last evaluated to, and CSV can only carry one of them at a time. Exporting the calculated value is what most systems expect to import. Exporting the formula text instead is what a human reviewer wants to read. Dates deserve the same explicit care. Writing them out in one fixed, chosen format, rather than trusting whatever the spreadsheet happened to display, stops the same file from producing different-looking dates depending on which machine's regional settings did the formatting.

Common mistakes, and the setting that prevents each one

Leaving the decimal separator on dot. A semicolon-separated export from a country that writes one and a half as 1,50 needs Decimal separator set to Comma in CSV to Excel; otherwise every price stays a string and refuses to be summed. Trusting automatic typing with identifiers. It protects leading zeros and anything over fifteen digits, but an order number or a postcode without a leading zero still becomes a number; when no column needs arithmetic, Cell types set to Everything as text keeps every value exactly as written. Pushing an export of a few million rows into one workbook. XLSX stops at 1,048,576 rows, so a longer CSV is refused with a link to Split CSV instead of being cut off without a word.

Going back out, compare three defaults in Excel to CSV with whatever reads the file next. Output encoding is UTF-8 with BOM, the form Excel needs; a script or a database loader usually wants plain UTF-8. Date format is ISO 8601, so 14 March 2026 becomes 2026-03-14 on every machine, with 14.03.2026, 03/14/2026 and the Excel serial number as the alternatives. Line endings are CRLF for Windows, with LF for Unix tools. A fourth setting is easy to miss: only the first sheet is exported by default, so a workbook with a second tab needs All sheets, which returns a ZIP with one CSV per sheet.