A French CSV: semicolons, decimal commas, and a space you cannot see
A French export puts semicolons between the fields and a comma inside the numbers, and it groups thousands with a space — very often a no-break space, which looks like an ordinary space and behaves like a letter. That last one is the reason a French file can pass through a converter and still refuse to add up.
What a French file usually looks like
Saved by a spreadsheet set to French (France), the file has a semicolon between the fields, a comma as the decimal mark and a space between thousands, so one thousand two hundred and thirty-four and a half is written 1 234,56. Dates are written DD/MM/YYYY: the last day of 2026 is 31/12/2026.
The separator is not a character any of the numbers contain, so nothing in the file needs quoting to survive — which is exactly why the amounts and the fields can be told apart at all.
None of this is a rule the file carries with it — there is no country written inside a CSV. It is what the program that wrote the file was set to, which is why every tool here reads the bytes and says what it found rather than trusting a flag.
The space is the part that catches people
In a French file, one thousand two hundred and thirty-four and a half is written 1 234,56. The gap is usually not the space bar character but a no-break space, the one word processors and spreadsheets use to stop a number breaking across a line. On screen the two are identical. To every tool that reads numbers they are not: a value with either kind of space in it is text, not a number, and it stays text however the rest of the file is converted.
This has a consequence worth knowing before you start, because it is the opposite of what the German page says. The delimiter fixer here converts a decimal comma when nearly every value in the column reads as a number under the European rules. A French column of 89,50 and 410,00 qualifies and is converted; a column that also holds 1 234,56 and 24 680,00 does not, because those two are not numbers to the detector, and so nothing in that column is rewritten at all. The tool leaves it alone rather than converting half a column, which would be worse.
So a French file with grouped amounts is a two-step job: take the spaces out first with find and replace, then convert. Do it in that order and the whole column qualifies; do it the other way and the amounts come through untouched.
Taking the spaces out, then converting
Find and replace here works on the text of the file, so it does not mind that the fields are separated by semicolons. Search for the space between the digits — copy it out of one of your own values rather than typing one, because that is the only way to be sure you have the same character — and replace it with nothing. The count of replacements tells you whether you caught them all.
With the spaces gone the amounts read as 1234,56 and the delimiter fixer converts the column, reports how many values it changed, and writes a comma-separated UTF-8 copy. Accented names survive the encoding step: a Windows-1252 export whose é arrives as é is decoded by what the bytes actually are, not by what the extension claims.
French dates are written 31/12/2026, the same slashes an American file uses in the other order, so a date under the thirteenth is ambiguous between the two readings. The console reads the column with strptime and the pattern %d/%m/%Y; the page for American files shows the same trap from the other side.
The sample file
Facture;Client;Date;Montant
INV-1001;Exemple SARL;31/12/2026;1 234,56
INV-1002;Modèle SA;02/03/2026;89,50
INV-1003;Specimen SAS;05/06/2026;32,10
INV-1004;Échantillon SARL;12/11/2026;24 680,00
INV-1005;Demo SA;20/01/2026;410,00
Obviously made-up data, small enough to read. Download it and drop it on the tool to see the fix before trying your own file.
Questions
- Why does my French CSV open as a single column?
- Because the fields are separated by semicolons and whatever opened it expected commas. The file is not damaged; it is correct for a French system and unreadable to a tool that was told to expect something else.
- Why were my amounts not converted?
- Almost certainly the thousands spaces. A value like 1 234,56 does not read as a number, so the column falls below the bar for conversion and is left whole rather than half-converted. Remove the spaces first and it converts.
- How do I know if the space is a no-break space?
- You cannot tell by looking, which is the problem. Copy the gap out of one of your own values and paste it into the search box rather than pressing the space bar; if the replacement count comes back zero, it was the other kind.
- Why does é show up as é in my file?
- The bytes are being read as the wrong encoding. The file is fine and the fix is automatic here: it is decoded by what it actually is and the copy you download is clean UTF-8.
- Is 01/02/2026 the first of February or the second of January?
- In a French file, the first of February — day first. Read by an American tool it becomes the second of January, with no error shown. Only the file itself can settle it, which is why dates are read with an explicit pattern here.
- Does my French export leave the browser?
- No. Both steps — the replacement and the conversion — run in the page on your own machine, and the browser is told to block outbound connections, so there is nothing to intercept.