Change CSV Delimiter

Semicolons to commas, commas to semicolons, or either to tabs or pipes. You do not have to know what your file uses now, and the quoting is redone properly so the fields that contain the new separator survive it.

Need to fix the numbers or the dates while you are in there? Open the app

Why your CSV came out full of semicolons

Excel does not really have a CSV format. It has a list format, and the character it puts between fields, both when saving and when opening a file by double click, is whatever Windows calls the List separator in the regional settings. On an English (United States) machine that character is a comma and everything behaves the way the file extension suggests. Where the decimal point is written as a comma, which is most of Europe and Brazil, the comma is already busy, so Windows makes the list separator a semicolon and Excel follows.

After that the confusion writes itself. A colleague in Munich saves Bestellungen.csv and it goes out with semicolons. Your tool reads one column per row with semicolons sitting inside it. Send a comma file back and Excel in Munich drops the whole row into column A, because it looked for a semicolon and found none. Neither file is broken and neither person made a mistake. The format never said which character it meant, and the two machines answered differently.

Everything downstream inherits the argument: import wizards that stop to ask, a sep=; line at the top of a file that some readers honour and others display as a stray row, spreadsheets that guess and get it wrong on the one file where a description contains a semicolon. Changing the character inside the file is the version of the fix that stays fixed, because it travels with the file instead of living on one machine.

Worked example: a parts list from a German Excel

Semicolons between the fields, commas inside two descriptions, and prices written with a decimal comma:

sku;description;price;qty
A-1001;"Bolt, hex, M6";0,45;120
A-1002;"Washer, flat";0,08;900
A-1003;Nut M6;0,12;1500

Set the output separator to comma, leave quoting on only where needed, and you get:

sku,description,price,qty
A-1001,"Bolt, hex, M6","0,45",120
A-1002,"Washer, flat","0,08",900
A-1003,Nut M6,"0,12",1500

Three things moved. The descriptions kept their quotes, since they still hold commas and the comma now means something. The prices gained quotes they never had, for the same reason: 0,45 would otherwise arrive as two fields. Nut M6 needed quotes under neither separator and has none. The summary line reads read as semicolon-separated, written as comma-separated, quoted only where needed, 3 rows x 4 columns, and a file named parts.csv comes back as parts-comma.csv, named that way so it cannot land on top of the file you started with.

Ask for tab instead and those same rows come back separated by tab characters with no quotes anywhere, because no field contains a tab, and the same input comes back as parts.tsv with the tab-separated media type on it. Switch quoting to quote every field and everything gets wrapped, numbers included, which is what a handful of stricter loaders insist on and what nothing else needs.

What the rewrite actually does

You are not asked what your file uses now. Comma, semicolon, tab and pipe are each tried against the text, the one that parses it into a consistent shape wins, and the answer is printed in words above the result. If the guess is ever wrong you will see it there rather than discovering it three steps later.

The rows are then parsed with quoting honoured, so a field holding the old separator stays a single field, and written back out with quoting recalculated against the new one. That mirror image is the whole reason this is not find and replace. Swapping every semicolon for a comma in a text editor wrecks every description that legitimately contained a comma, and turns every European price into two columns. Parse first, write second, and the structure is understood before it is changed.

Cell contents are carried across as the exact characters they were. A product code of 00512 comes out as 00512, a date keeps whatever format it arrived in, nothing is rounded and nothing is localised. The only characters that change are the separators between fields and the quotes that protect them.

The Windows setting is the heavier fix

The first answer most searches turn up is to open Region, click into Additional settings, and edit the List separator there. It does work. It is also machine-wide and permanent until someone undoes it: every application that consults that setting changes behaviour, every CSV saved from then on uses the new character, and any macro or template built around the old one is now living in a different country. That is a heavy lever to pull because one attachment came from the wrong place, which is why the most upvoted replies in those threads spend their time warning people off it.

Two lighter moves exist. Inside Excel, the Data tab and From Text/CSV let you state the separator for one file without touching anything global, which is the right answer when you only need to read the thing. Or change the file itself, which is what this page is for, and hand the other person something their defaults already understand.

Worth checking in the output

Decimal commas stay decimal commas. Separators are the only thing being changed. A price of 0,45 comes through as 0,45 in quotes, and a spreadsheet expecting a decimal point will treat it as text. If the recipient needs real numbers, that column has to be converted deliberately, which is editing rather than rewriting.
A sep= line counts as data. If your file opens with sep=; on line one, that line is read as an ordinary row and becomes your header, pushing the real header down into the body. Delete it before converting; once the separator is the one the reader expects, the hint is not doing anything for you anyway.
No byte order mark is written. The output is plain UTF-8. If accented characters look mangled when the file is opened by double click, that is the spreadsheet guessing an encoding, and the import path is where you can tell it UTF-8 instead.
Ragged rows get squared off. A row with fewer fields than the widest one is padded with empty cells before writing, and a note tells you how many rows that applied to. If that number is large, the input probably has a quoting problem worth looking at first.
Line breaks inside a field survive. A multi-line address stays in one quoted field with its breaks intact, whichever separator you choose. It stays a single row too, so the row count does not drift.
Quote everything is not safer. It makes the file bigger and reads no differently to a correct parser; the minimal style already quotes each field that needs it. Reach for it only when something downstream has told you it wants that.

Frequently Asked Questions

Why does Excel save my CSV with semicolons?

Because Excel uses whatever Windows calls the List separator, not a comma. On a locale where the decimal point is written as a comma, which covers German, French, Dutch, Spanish, Italian and Brazilian setups among others, the comma is already spoken for, so Windows sets the list separator to a semicolon and Excel writes and reads CSV that way. The file is not corrupt. It was written by a machine that means something different by the word separator.

Will this change any setting on my computer?

No. It writes a new file with a different character between the fields, and your regional settings, your Excel options and the original file are all untouched. That is the point of doing it this way. Editing the Windows list separator also works, but it applies to every application and every file on the machine from then on, which is a lot of blast radius for one attachment.

What happens to a field that already contains the new separator?

It gets wrapped in double quotes, which is what keeps it one field. Rewriting a semicolon file to commas will therefore add quotes around any description that had a comma inside it, and remove quotes from fields that only needed them under the old separator. That requoting is why this is not the same as find and replace in a text editor, which breaks exactly those fields.

My prices use a comma as the decimal point. Does that get converted?

No, and it is worth knowing before you send the file on. A value of 0,45 is copied across as the characters 0,45, and since it now contains the separator it comes out quoted. Excel on a locale that expects a decimal point will then read it as text rather than as a number. Changing decimal marks means deciding which columns hold numbers at all, which is an editing job rather than a separator job, so the full editor is the place for it.

Can it write tab separated files?

Yes. Choose tab as the output separator and the download is named with a .tsv extension and carries the tab separated media type, because calling a tab file .csv confuses roughly everything downstream. Tab output is also the answer when a field is full of both commas and semicolons, and when someone wants a block that pastes into Word or Outlook as a real table.

Is the file uploaded, and how large can it be?

It is not uploaded. Reading, parsing and rewriting all happen in the browser tab you have open, so the price list or payroll export never travels anywhere. Files up to 100 MB are accepted with no limit on rows, and anything larger is handed over to the full editor, which reads a file in pieces rather than all at once.

Give the file the separator it needs

Drop the CSV, pick comma, semicolon, tab or pipe, and read the line that says how yours was understood. Free, no sign-up, and your regional settings stay exactly as they are.

Back to the converter