Skip to content
Morphr

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

By Andrew Butson · July 2, 2026 · 6 min read

You open a CSV someone sent you and instead of neat columns, every row lands in column A as one long comma-separated string: Name,Email,Order Total,Date all crammed into a single cell, repeated down the sheet. The file looks fine in a text editor; every value is there, separated by commas exactly as a CSV should be. Excel just isn't splitting it.

This is one of the most common CSV complaints there is, and it's almost never a broken export. It's Excel's default delimiter disagreeing with the character actually separating your values, which usually comes down to a regional settings mismatch you can fix in under a minute once you know where it lives.

Why it happens: "comma-separated" isn't universal

CSV stands for comma-separated values, but the actual separator a program uses to write and read one depends on the regional settings of the machine involved. In locales where the comma is already used as the decimal separator (much of continental Europe writes 3,14 rather than 3.14), Windows and Excel both default to the semicolon as the list separator instead, precisely to avoid ambiguity with decimal numbers. A CSV exported on a machine set to one of those locales is a genuine, valid CSV; it's just semicolon-delimited rather than comma-delimited.

Double-clicking a .csv hands it to Excel using your machine's own regional default, not whatever the file was actually built with. If your Excel is set to expect commas and the file uses semicolons (or the other way around), Excel doesn't detect the mismatch and ask; it simply fails to find any of "its" delimiter in each line and treats the whole line as a single field. A less common but related cause is encoding: a CSV saved with a UTF-8 byte-order mark that the receiving version of Excel doesn't strip cleanly can also garble the very first column header, though that shows up as one odd cell rather than every row collapsing into one.

The fix that actually prevents it: import, don't double-click

Opening the file through Excel's import tool, rather than double-clicking it, lets you tell Excel what the delimiter actually is instead of relying on its regional guess:

Convert CSV to XLSX — free, in your browser

Reads the real delimiter and writes proper columns into a genuine .xlsx workbook, so Excel never has to guess.

Runs entirely in your browser — nothing is uploaded.

Where converting the file first actually helps

Every fix above works by intervening before Excel applies its default guess, whether by importing instead of double-clicking, or by explicitly setting the delimiter. Converting the CSV into a real .xlsx workbook first does the same job at the file level: Morphr's CSV-to-XLSX conversion reads the CSV's actual delimiter and writes proper columns into a genuine Excel workbook, so double-clicking the result opens correctly split every time, on any machine, regardless of that machine's regional settings.

That's particularly useful if you're the one distributing the file. Sending a CSV export to a team where you don't control everyone's Excel regional settings means some of them will hit the one-column problem and some won't, purely based on their machine's configuration. Shipping an .xlsx instead removes the guess entirely, for everyone who opens it.

It's worth reading alongside Morphr's other CSV-and-Excel article, on why Excel silently rewrites numbers and dates when it opens a CSV, a related but separate problem that shows up even when the delimiter is correct and the columns split fine.

Frequently asked questions

How do I know if my CSV uses semicolons instead of commas?
Open it in a plain text editor (Notepad, TextEdit) rather than Excel. If the values are separated by semicolons rather than commas, that's your delimiter, usually because the file was created on a machine set to a locale that uses the comma as a decimal separator.
Will changing my Windows regional list separator fix this for every CSV, permanently?
For CSVs using your new default delimiter, yes, but it's a machine-wide setting, so it also affects other regional formatting, and it won't retroactively help a CSV that uses a different delimiter than the one you just set. Importing with an explicit delimiter choice is the more reliable habit either way.
Is this the same problem as Excel changing my dates and numbers?
No. This is Excel failing to split columns at all, which is a delimiter mismatch, while the dates-and-numbers problem happens after columns are already split correctly, when Excel's type-guessing reformats a value it thinks it recognises. Both are regional-settings-driven CSV problems, but they need different fixes.
Does converting to XLSX fix data that's already been mangled by a bad CSV open?
Only if you still have the original CSV to convert from. The one-column problem itself is visual and structural rather than destructive: the underlying values in the CSV are unaffected by Excel failing to split them. But you need to convert from that original file, not from a copy you've already saved out of the broken view.