How to export Excel to clean UTF-8 CSV without corrupted characters

Comma-Separated Values (CSV) is the common language of database imports, AI training datasets, financial audit ledgers and API data pipelines. Almost every program can read it. Yet exporting a spreadsheet from Microsoft Excel into a clean CSV file often damages the data in small ways that are easy to miss: garbled accented letters (mojibake), leading zeros stripped from postal codes, semicolons used instead of commas in some regions, and mangled date formats.

---

Chapter 1: The Technical Anatomy of CSV and RFC 4180

CSV looks very simple, just text separated by commas. But it has a written standard: IETF RFC 4180. When Excel exports a workbook, it often breaks these rules because of the regional defaults of your operating system:

1.1 Character Encoding: ANSI vs. UTF-8 vs. UTF-8 with BOM

On a standard Windows installation, Microsoft Excel saves CSV files in the old Windows ANSI code page by default (for example, Windows-1252 in Western Europe and the US, or Windows-1251 in Cyrillic regions). Suppose an ANSI-encoded CSV contains international characters such as München, São Paulo or Tokyo (東京), and you upload it to a Linux server or a modern cloud database (PostgreSQL, Snowflake, BigQuery). The characters are read as raw single bytes, and you get garbled mojibake text (for example, München or São Paulo).

On the other hand, when Excel saves as "CSV UTF-8", it puts a 3-byte Byte Order Mark (BOM: 0xEF, 0xBB, 0xBF) at the very start of the file. The BOM tells Excel the file is Unicode (the Unicode BOM FAQ explains how it works). But many backend parsers in Python (pandas.read_csv without encoding='utf-8-sig') or Node.js read the BOM as ordinary characters. This spoils the name of the first column header (you get "id" instead of "id").

1.2 The European Semicolon Delimiter Collision

In countries that use a comma as the decimal separator (for example Germany, France, Italy, Spain and Brazil), 12,50 means twelve and a half. Since the comma is taken for decimals in these regional settings, Excel uses a semicolon (;) as the column separator when it exports CSV. Give that file to an international data platform that expects commas, and each row with many columns is read as one long string.

---

Chapter 2: The Top 5 Excel Export Nightmares and How to Prevent Them

2.1 The Vanishing Leading Zero Disaster

Excel guesses data types automatically, and it assumes that any string made only of digits is a number. As a result:

• US ZIP codes like Boston's 02134 become the integer 2134.
• International phone numbers like +0123456789 or 0800-123456 lose their leading zeros.
• Employee ID numbers and bank routing codes that start with zeros are ruined.

To keep leading zeros during export, the data has to be treated as text and wrapped in RFC 4180 quotes.

2.2 Scientific Notation Truncation on Large IDs

Excel converts any number longer than 11 digits into scientific notation (for example, 7.011E+17). This hits 16-digit credit card numbers, 13-digit EAN/UPC barcodes and long account or order numbers like 123456789012345678. Excel also keeps only 15 digits of precision. If you save without care, Excel writes the scientific-notation text to disk, and the trailing digits are lost for good.

2.3 Embedded Commas, Quotes, and Multi-line Newlines

Under RFC 4180, if a cell contains a comma (for example, "123 Main St, Suite 400"), the whole field must be wrapped in double quotes. If the cell contains a quote character (for example, 24" Monitor), that quote must be escaped by doubling it ("24"" Monitor"). If a cell contains a line break (Alt+Enter in Excel), the surrounding quotes must span the lines so that the row is not split in two.

---

Chapter 3: Technical Comparison of CSV Export Methods

Export Method	Encoding Standard	Leading Zeros	Quote Escaping	Database Ingestion Readiness
Excel Standard "Save As CSV"	Windows-ANSI (Corrupts Accents)	Stripped / Lost	Partial / Inconsistent	Poor (Requires Cleaning)
Excel "CSV UTF-8"	UTF-8 with BOM (Breaks Parsers)	Stripped / Lost	Standard	Moderate
ToolXkit In-Browser Engine	Pure UTF-8 (No BOM Header)	100% Preserved	Strict RFC 4180	Production Ready (PostgreSQL, BigQuery)

---

Chapter 4: Step-by-Step Guide: Generating Clean Production CSVs

1. Step 1: Clean Up Header Rows: Remove blank lines, merged header cells and decorative title banners from row 1 of your Excel sheet. Row 1 should contain only unique, lowercase column names made of letters and numbers (for example, customer_id, transaction_date, order_total).
2. Step 2: Format Date Columns to ISO 8601: Make sure every date uses the international format YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ, which cannot be misread. Avoid regional formats like MM/DD/YYYY or DD/MM/YYYY: any date whose day is 12 or lower can be read two ways, because nothing tells you which number is the day.
3. Step 3: Convert Formulas to Raw Calculated Values: If your sheet uses VLOOKUP, XLOOKUP or other formulas that recalculate, make sure all the results have finished calculating before you convert.
4. Step 4: Execute In-Browser Client-Side Conversion: Drop your XLSX workbook into the Excel to CSV converter. The SheetJS engine reads the XML cell records inside the file right in your browser's memory, and produces a clean RFC 4180 UTF-8 CSV without sending your data anywhere.

---

Chapter 5: Enterprise Privacy & Compliance

Spreadsheets often hold a company's most sensitive data: customer contact details, employee salaries, quarterly financial statements and internal pricing models. Uploading these XLSX files to a random online converter puts your organisation at risk of data breaches, leaks to competitors and trouble with GDPR rules.

ToolXkit does all the unpacking, cell formatting and text output locally, in JavaScript running in your browser. So zero bytes of your spreadsheet ever leave your computer. To check the result before you send it on, open the file in the CSV viewer.