Skip to main content

CSV Opens in One Column: Semicolons, Commas, and Your Locale

The symptom tells you the file and the program disagree — not which of them is wrong. Before changing any Excel setting, it is worth establishing what delimiter the file actually contains, because half the time the file is fine.

The short answer

Everything landing in column A means the delimiter in the file is not the one the spreadsheet split on. That happens two ways, and they look identical on screen:

The file really does use semicolons, and the program expected commas. Or the file is ordinary comma-delimited CSV and the program is splitting on a different separator because of a regional setting. In the second case the file is not wrong at all, and editing it would be the wrong move.

So the first step is not to change a setting or run a find-and-replace. It is to find out what the file actually contains.

Why it all lands in one column

A CSV file does not record which delimiter it uses. Nothing in the format announces it — a reader has to work it out, or be told. Spreadsheet applications typically resolve that by using the list separator configured on the machine, which is why the same file can open perfectly on one computer and as a single column on another.

When the separator does not match, the split simply does not happen. Each line becomes one long value, and every row lands in the first column with its delimiters still visible inside the text. Nothing has been lost or corrupted — the file is intact and merely unsplit.

Is the file comma- or semicolon-delimited?

Counting characters by eye is unreliable, because a delimiter may legitimately appear inside a quoted value. These two rows have the opposite delimiter to the one that occurs most often:

InputReportedFirst row parsed
name,city,amount ada,london,1.50The ordinary case, and a decimal point in the amount.Detected delimiter: comma (,){"name":"ada","city":"london","amount":"1.50"}
name;city;amount ada;london;1,50A decimal comma inside the value, which is why the file uses semicolons.Detected delimiter: semicolon (;){"name":"ada","city":"london","amount":"1,50"}
name city ada londonOften produced by pasting out of a spreadsheet.Detected delimiter: tab{"name":"ada","city":"london"}
name|city ada|londonCommon in exports that expect commas inside values.Detected delimiter: pipe (|){"name":"ada","city":"london"}
name;note ada;"Doe, Jane"The comma stays inside the value rather than splitting it.Detected delimiter: semicolon (;){"name":"ada","note":"Doe, Jane"}
name,note ada,"a;b;c"More semicolons than commas, and still a comma-delimited file.Detected delimiter: comma (,){"name":"ada","note":"a;b;c"}

Note the last two rows in particular. A semicolon file can contain more commas than semicolons, and a comma file can contain more semicolons than commas, once quoted values are involved. That is why a find-and-replace on delimiters is risky: it does not know which characters are structure and which are content.

Why locales change the expected separator

The reason semicolons exist in CSV at all is the decimal comma. Where 1,50 means one and a half, a comma cannot also separate fields without ambiguity, so the convention shifts to a semicolon.

Decimal separatorUsual list separatorCommon in
Period — 1.50CommaUK, US, and much of Asia
Comma — 1,50SemicolonGermany, France, Spain, Italy, Brazil, and much of Europe

This is the general convention rather than a rule. Which setting a spreadsheet consults, and how strictly, varies between versions and between Windows, macOS, and the web builds — so treat it as the reason the mismatch is common, not as a prediction about a particular machine. The practical consequence is the durable part: a correct file exported in one country can open as one column in another, with nothing wrong with it.

What sep=; means

A first line of sep=; is a directive telling Excel which delimiter to use. It is an Excel convention, not part of the CSV format, and a parser that does not know about it will read it as an ordinary first row — which shifts every column by one row.

sep=;
name;city
ada;london
bob;paris

The CSV Converter recognises a supported directive, drops the line from the data, uses the delimiter it declares, and says so:

Declared delimiter: semicolon (;) — from a sep= line in the file.

[
  { "name": "ada", "city": "london" },
  { "name": "bob", "city": "paris" }
]

# The sep= line is metadata, so it is not a row and "name" stays the header.

It is a reasonable way to make a file open predictably in Excel. It is worth knowing that it travels badly: any consumer that does not implement the convention sees a stray row, so it is a fix for a spreadsheet audience rather than a general one.

Diagnosing the file

The point of this sequence is to find out which of the two causes you have before changing anything:

  1. 1. Paste the file into the CSV ConverterPaste the raw text, not a screenshot of the spreadsheet. If the file is large, the first twenty lines are enough — the delimiter is established by the header and the first rows.
  2. 2. Read the reported delimiterIt states what the parser found in the text you pasted, and says whether that came from the data or from a sep= line the file declared.
  3. 3. Check that the columns split where you expectA reported delimiter is only half the answer. Look at the first row of JSON: the keys are the header fields, and each value should be one cell rather than several run together.
  4. 4. Parses correctly here, one column in Excel? Look at ExcelThe file is consistent with itself, so the disagreement is in how it is being opened. The import route — choosing the delimiter explicitly — avoids the system setting entirely.
  5. 5. Parses incorrectly here too? Look at the fileA file that neither program can split has a problem of its own — a delimiter that appears inside unquoted values, mixed delimiters between rows, or a quoting fault. The other CSV guides cover those.

Paste the file into the CSV Converter and it reports the delimiter it used, then converts the rows so you can see whether the columns landed where you expected. A file exported from Excel as UTF-8 often begins with a byte order mark. It is handled and does not end up inside the first column name.

What it cannot do is worth stating plainly. It does not inspect your spreadsheet settings, does not know your locale, cannot change any Excel configuration, and cannot promise how another application will import the same file. It reads the text you paste and tells you what is in it. Conversion runs in your browser, so a file containing real data is not uploaded anywhere.

When the file is fine and Excel still is not

If the delimiter is what you expected and the columns parse correctly, the file is consistent and the disagreement is in how it is being opened. Four options, roughly in order of how targeted they are:

  • Use the import route rather than double-clicking. Opening a CSV through Data → Get Data → From Text/CSV lets you choose the delimiter for that file, instead of relying on a system-wide setting.
  • A sep= line at the top of the file declares the delimiter to Excel. It is an Excel convention rather than part of CSV, and most other tools will treat it as data unless they specifically support it.
  • Changing the Windows list separator changes it for every application and every file. It works, and it is the least targeted of the options.
  • Re-exporting with the delimiter the recipient expects is usually the durable fix when you control the producer, because the file then opens correctly regardless of who receives it.

One thing to avoid: replacing every semicolon with a comma in a text editor. If any value contains a comma or a semicolon of its own — a name, an address, a decimal number — that replacement changes the data rather than the structure, and the damage is not obvious afterwards.

Related CSV problems

Three different symptoms, three different causes. If the delimiter is right but the rows do not all have the same number of fields, that is rows with a different field count. If you get back far fewer rows than the file appears to contain, a quote was probably left open — an unterminated quoted field absorbs everything below it.

The quick test: one column means a delimiter problem, too few rows means a quoting problem, and the right rows with uneven widths means a field-count problem.

Behaviour measured

The delimiters, notices, and parsed rows on this page were produced by:

  • Papa Parse5.5.4 (header: true, skipEmptyLines: true)
  • DataToolsHQ CSV ConverterPapa Parse 5.5.4

The spreadsheet behaviour described is the general convention rather than measured output — it varies by application, version, and platform, and this page does not test it.