Why Your CSV Opens as One Column in Excel (and How to Fix It)

Everything crammed into column A is almost never a broken file. It is Excel using your regional list separator instead of the comma — plus two related problems that silently corrupt your data.

You open a perfectly valid CSV and every row lands in column A, commas and all. The file is fine. Excel simply did not split it, because Excel does not assume a comma separates the values in a "comma-separated values" file — it uses whatever your operating system has configured as the regional list separator.

The cause is your regional settings, not the file

In English-language locales that separator is a comma, so CSVs open correctly and nobody notices this behaviour exists. In Spanish, German, French, Italian and most other European locales, the decimal separator is a comma, so the list separator is a semicolon instead. Excel opens your comma-delimited file, looks for semicolons, finds none, and concludes the whole line is a single value. This is also why a colleague can open the exact same file without any problem while yours looks broken — you have different regional settings, not different files.

Three ways to fix it, from quickest to most reliable

The fastest fix is to add a single line at the very top of the file reading sep=, followed by nothing else. Excel treats that first line as an instruction rather than data and uses the separator you named. The second option is to not double-click the file at all: open Excel first, then use Data > From Text/CSV, which launches the import wizard and lets you choose the delimiter explicitly. The third, useful when you cannot modify the file, is to rename the extension from .csv to .txt — Excel refuses to guess for a .txt file and always shows the import wizard. The import wizard is the only approach that also solves the two problems below, which is why it is worth the extra clicks.

The second problem: accented characters turn into mojibake

If names appear as José or Müller, the file is UTF-8 but Excel decoded it as a legacy single-byte encoding. Excel only auto-detects UTF-8 when the file starts with a byte order mark, an invisible three-byte prefix that most export tools and most programming languages omit by default. You have two options: save the file as "UTF-8 with BOM", or use the import wizard and set File Origin to 65001: Unicode (UTF-8). Note that the mangling happens at import time, so fixing it after the fact by find-and-replace is hopeless — reimport instead.

The third problem: leading zeros and long numbers get destroyed

Excel aggressively guesses types. A postal code like 01234 loses its leading zero and becomes 1234. A 16-digit order ID becomes 1.23457E+15 and the original digits are gone for good. A value like 1-2 can become a date. None of this is recoverable once the file is saved, and it is the single most common way CSV data silently corrupts in the wild. The only real defence is the import wizard: in the final step, select those columns and set their type to Text before finishing. If you are generating the CSV yourself, wrapping such values in quotes does not help — Excel still converts them.

If you are producing the file rather than receiving it, our JSON to CSV converter lets you pick the delimiter and encoding up front, so the file opens correctly for whoever receives it. Everything runs in your browser, so customer or order data never leaves your machine.