Why Excel Mangles Your CSV (and How to Fix Encoding Issues)
Why Excel shows garbage characters or wrong columns
Excel breaks CSV files in two predictable ways: it displays gibberish instead of accented or non-Latin characters because it opens UTF-8 files as ANSI, and it puts all data in one column or splits it incorrectly because it expects semicolons when your file uses commas (or the reverse). The first problem happens because UTF-8 files without a byte-order mark look identical to ANSI files at the binary level, so Excel guesses wrong. The second happens because Windows region settings determine which character Excel treats as the default separator—comma in English-speaking regions, semicolon in much of Europe.
The encoding problem: UTF-8 without BOM
When you double-click a CSV file, Excel does not check for UTF-8 encoding markers. It opens the file using your system's default ANSI code page (Windows-1252 in the US, Windows-1251 in Russia, and so on). A UTF-8 file can include a three-byte signature at the start—the byte-order mark—that tells programs "this file is UTF-8." Most modern programs that export CSV skip this BOM because the Unicode standard calls it optional and some Unix tools reject files that contain it. Excel requires it.
If your CSV contains only ASCII characters (basic English letters, digits, common punctuation), you will not notice the problem because UTF-8 and ANSI encode those identically. The moment your data includes è, ñ, ü, Cyrillic, Chinese, emoji, or any character outside the legacy code page, Excel renders nonsense. The file is not corrupt—Notepad, Google Sheets, and LibreOffice usually open the same file correctly because they probe for UTF-8.
The delimiter problem: regional list separators
CSV stands for comma-separated values, but Excel does not always expect commas. Windows maintains a regional setting called the "list separator," found in Control Panel under Region → Additional Settings → Numbers. In English (United States), this separator is a comma. In German (Germany), French (France), and many other locales, it is a semicolon, because those regions use a comma as the decimal separator in numbers (5,2 instead of 5.2). Excel uses your list separator as the default delimiter when opening a CSV by double-click.
If someone in France receives a comma-delimited file from an English system and double-clicks it, Excel puts every row into column A as one long string. If someone in the US opens a semicolon-delimited file from Germany, the same thing happens in reverse. The file is valid CSV by any reasonable definition—the problem is that "CSV" has no universal standard, and Excel privileges local settings over inspection of the actual delimiter in the file.
Fix for encoding: import instead of open
Do not double-click the CSV. In Excel, go to Data → Get Data → From File → From Text/CSV (Excel 2016 and later) or Data → From Text (earlier versions). Excel opens an import wizard that lets you specify UTF-8 encoding explicitly. In the preview window, choose "65001: Unicode (UTF-8)" from the File Origin dropdown. This forces Excel to interpret the bytes correctly, whether or not a BOM is present.
If you control the CSV export process, add a UTF-8 BOM. In Python, use encoding='utf-8-sig' when opening the file for writing. In Notepad, save as UTF-8 with BOM (not "UTF-8," which omits it). In many server-side frameworks and database exports, you must set this explicitly—UTF-8 without BOM is the default because it avoids issues on Linux and in JSON parsers.
Fix for delimiters: specify in the import dialog
The same import wizard (Data → From Text/CSV) previews the file and usually auto-detects the delimiter. If it guesses wrong, click the dropdown next to Delimiter and choose Comma, Semicolon, Tab, or Custom. Excel will re-parse the preview. Confirm that columns break in the right places before clicking Load.
If you want double-click to work, you can change your Windows list separator in Region settings to match the files you receive most often, but this affects all applications and changes how Excel writes its own CSV files. It is not a practical solution if you exchange files internationally. The correct long-term approach is to use the import wizard or automate the process with Power Query, which remembers your encoding and delimiter choices per connection.
FAQ
Why does the same CSV open correctly in Google Sheets but not Excel? Google Sheets probes the file for UTF-8 encoding and common delimiters when you upload it, rather than relying on system locale defaults. Excel uses your Windows regional settings and assumes ANSI encoding on double-click.
Can I make Excel always treat CSV as UTF-8? No built-in setting does this. You must use the import wizard each time, or save the import steps as a Power Query connection you can refresh. Changing the system code page is not recommended because it breaks other legacy software.
Does adding a BOM break anything? Some Unix tools and older parsers reject or visibly include the BOM bytes, and the BOM is invalid in UTF-8 JSON. If your CSV stays within the Microsoft ecosystem (Excel, Power BI, SSMS), a BOM is safe and solves the problem.
Avoiding the problem in automation
If you generate CSV files programmatically for Excel users, include the UTF-8 BOM and use the semicolon delimiter if your audience is primarily in Europe, or provide both versions. If your workflow involves frequent CSV imports, consider using Excel's native formats (XLSX) or a file-conversion service that handles encoding transparently. OmniDesk supports conversion between CSV dialects and XLSX with explicit encoding control, which removes guesswork when you distribute data across regions—you can read more about supported formats and preview the output before final export. Many organizations script the import step with Power Query or VBA to enforce UTF-8 and the correct delimiter, so end users only double-click a macro-enabled workbook that fetches the latest CSV behind the scenes. That approach ensures consistency without retraining users or changing system settings on every machine.