Semicolon vs Comma in CSV: Why Excel Disagrees

Your CSV file isn't broken. Excel is just reading it in the wrong language.

You export a report, double-click the .csv, and every row lands crammed into column A — names, dates, totals, all mashed into one cell with the commas still sitting between them. Or the opposite: a colleague in Berlin opens the clean file you sent and it explodes into a wall of semicolons. Nothing is corrupt. The bytes are fine. You and Excel simply disagree about which character means "next field," and that disagreement has a specific, fixable cause.

Here's what's actually going on, why it's a regional setting rather than a bug, and how to fix it without mangling your data along the way.

The comma was never guaranteed

It's tempting to assume the C in CSV settles the argument — comma-separated values, case closed. The reference specification (RFC 4180) does name the comma as the delimiter. But Excel doesn't consult that spec when it opens a file. It reads your operating system's regional "list separator" setting, and across a large part of the world that setting is a semicolon.

So the file you saved with commas is, by the letter of the standard, a correct CSV. And Excel refusing to split it on commas is, by its own rules, also correct. Two tools both doing the right thing and still producing a broken-looking screen — that's what makes this one so disorienting the first time it happens to you.

Why a whole continent switched to semicolons

The reason isn't arbitrary, and once you see it you can't unsee it: it's the decimal comma.

In the US and the UK you write one thousand and a half as 1,000.5 — the comma groups the thousands, the dot marks the decimal. In much of Europe and South America it's the mirror image: 1.000,5. There, the comma is the decimal point. Now try to reuse that same comma to separate fields in a table. Is 1,5 one value (one and a half) or two values (a 1 and a 5)? There's no way to tell. The comma is already busy.

So those locales give the separator job to a character that isn't doing anything else — the semicolon — and Excel follows the regional setting. The delimiter didn't change because someone preferred the look of it. It changed because the comma was already spoken for.

Think of it like which side of the road you drive on. Same car, same road, identical laws of physics — but cross a border and the convention flips, and a driver running on muscle memory from home is suddenly a hazard. A comma crossing from a US file into a German copy of Excel is that driver: doing exactly what it always did, in a place where it now means something else.

Don't fix it with find-and-replace

The obvious fix is a bulk search: replace every comma with a semicolon and move on. Do that and you'll manufacture a worse problem than the one you started with.

The moment a field contains a comma — Portland, OR, a price like $1,299, any quoted sentence — a blind replace turns that single value into two, and every column after it shifts one to the right. This is the exact failure I walked through in how to clean a messy CSV: the delimiter and the data are fighting over the same character, and a naive replace always sides with the delimiter. If you want the full tour of how quoting is meant to protect those fields, what a CSV actually is covers the escaping rules end to end.

The fixes that actually hold

There are three reliable moves, roughly ordered by how permanent you want the fix to be.

Tell Excel the delimiter directly. Add a single line — sep=; or sep=, — as the very first line of the file, above the header row. Excel reads it and uses that separator no matter what the regional setting says, and most other tools quietly ignore it. It's a one-line hint that overrides the whole locale guess, which is handy when you're emailing a file to someone whose Excel you can't configure.

Convert the delimiter properly. When you need the file itself to change — not just how one program reads it — use a converter that understands quoting. A CSV delimiter converter rewrites only the structural separators and wraps any field containing the new delimiter in quotes, so a value like Portland, OR survives the switch from comma to semicolon intact. For the tab case specifically, CSV to TSV does the same job with tab separators, which sidestep the comma-versus-semicolon fight almost entirely — the reasoning there is the same one behind CSV vs TSV.

Look before you parse. Before any of that, confirm what you're actually holding. Open the file in a CSV viewer and watch where the columns break — if commas inside values are splitting your data, it's comma-delimited; if the rows only line up once you assume semicolons, that's your answer. The .csv on the end of the name promises nothing about what's inside it.

The move that ends the argument

If this file is one step in a pipeline rather than a one-off you're eyeballing, the durable fix is to stop passing delimited text between systems at all. Convert the table into structured data with a CSV to JSON step and the delimiter question disappears — JSON has exactly one way to separate values, and it reads the same in Tokyo, Toronto, and Turin. Every row is forced to carry the same keys, a ragged line fails loudly at the boundary instead of three tables downstream, and no regional setting can reinterpret it after the fact.

That's the real lesson hiding inside a column-A disaster: a comma isn't a neutral, universal separator. It's a local convention that happens to be common, and the semicolon is simply what you get when that local convention needed the comma for something else. Check the delimiter before you trust the file, convert it deliberately when you have to, and when the data has to travel between regions, hand it a format that doesn't change its mind at the border.