Convert Excel to CSV Without Uploading It

Updated 5 November 2026 · Free PDF Tools Online

CSV looks like the simplest format in computing: rows, columns, commas. In practice it is where more data gets quietly corrupted than anywhere else — accented characters turn into gibberish, account codes lose their leading zeros, dates swap day and month, and a price list arrives at a supplier with three of its five columns in the wrong place.

This page explains what actually happens when a spreadsheet becomes a CSV, how to convert locally without uploading, and how to check that nothing was lost in a format that has no data types at all.

CSV has no types — that is the whole problem

A spreadsheet cell knows what it holds: this is a number, this is a date, this is text. A CSV file knows nothing. It is a sequence of characters separated by commas and line breaks. Every interpretation happens later, when something opens the file — and different programs guess differently.

That single fact explains almost every CSV problem:

• 00123 becomes 123 — because the receiving program decides it is a number.
• 05/11/2026 becomes 11 May — because the receiving program uses its own locale to read the date.
• 1E5 becomes 100000 — because a product code that looks like scientific notation is read as a number.
• Text turns to gibberish — because the file's character encoding is not what the program assumed.

Encoding: why CSV files open as gibberish

Characters are stored as bytes, and the mapping from bytes to characters is the encoding. If the file is written as UTF-8 and read as something else, every non-ASCII character becomes wrong. Accented letters, Chinese, Japanese, Greek, Cyrillic and emoji all break; plain English is unaffected, which is why the problem can go unnoticed until a name like Zoë or Müller appears.

The common encodings you will meet:

If you are exporting from Excel on a Chinese or Japanese Windows machine using "Save as → CSV", the file is probably in the local codepage, not UTF-8. It will open correctly on that machine and incorrectly everywhere else.

The BOM, and when to use it

A BOM — byte order mark — is three bytes, EF BB BF, at the very start of a file. They carry no data; they are a flag that tells the reader "this is UTF-8".

Excel on Windows is the main reason BOMs exist in CSV files. Without a BOM it assumes the system codepage; with one it recognises UTF-8 and displays the text correctly. macOS and most programming languages handle the BOM transparently, though a few tools will show it as a stray character at the start of the first header cell.

Leading zeros, dates and other losses

These are the losses that pass unnoticed until someone downstream complains.

Leading zeros

00123 becomes 123. Invoice numbers, account codes, postcodes, phone numbers and product SKUs are all affected. The fix is to format the column as text before the data is entered or exported. If the export has already happened, you cannot recover the zeros from the CSV — the information is gone, so go back to the source.

Dates

A date written as 05/11/2026 is ambiguous between 5 November and 11 May, and the receiving program will pick according to its locale. Write dates as 2026-11-05 (ISO 8601) for any file that will be exchanged between systems or countries. It is unambiguous and sorts correctly as text.

Formulas

Only the calculated value is exported. The formula itself cannot be represented, because a CSV has no calculation engine. That is usually what you want, but it means a CSV is not a backup of a workbook — keep the .xlsx.

Number formatting

Currency symbols, thousands separators, percentages and custom formats are dropped. $1,234.50 becomes 1234.5. If a client expects the formatted version, a PDF is the right output, not a CSV.

Multiple sheets

A CSV holds one table. A workbook with three sheets produces three files, and the sheet names are lost unless you name the files after them.

Commas and line breaks inside fields

A description containing a comma would break the column structure, so the format wraps such fields in double quotes and doubles any internal quote. This is standard and correct, but if a tool produces the file without it, the import shifts every subsequent column by one — which is how a price list ends up with values in the wrong column.

Convert locally in the browser

Our PDF toolbox converts both ways in the page: .xlsx to CSV and CSV to .xlsx. Nothing is uploaded.

1. Open the toolbox and choose Excel ↔ CSV.
2. For Excel to CSV: select the .xlsx. The first worksheet is exported, since CSV cannot hold more.
3. For CSV to Excel: select the .csv. Each row becomes a row, and the output is a real .xlsx you can open and format.
4. Save the result and check the first row and one accented value before doing anything else with it.

The CSV written by a browser tool is UTF-8, which is the correct choice for interchange. Whether a BOM is added depends on the tool; if you are feeding Excel on Windows with Chinese or accented text, confirm the result before sending it on.

CSV back to Excel

The reverse direction has its own trap: opening a CSV directly in Excel applies the same guessing, so a UTF-8 file may open as gibberish. Use Data → From Text/CSV and set the encoding and delimiter explicitly. Once it is imported and looking correct, save it as .xlsx so the column types are preserved from then on.

Checklist before you import it anywhere

1. Open it in a text editor — not a spreadsheet. You should see commas and read the first line as plain text. If it looks like gibberish there, the encoding is already wrong.
2. Count the columns in the header and confirm every row has the same number of commas.
3. Look for a field containing a comma and confirm it is wrapped in quotes.
4. Check one value with an accent or a non-Latin character.
5. Check one code with a leading zero.
6. Check the date format, and rewrite to ISO 8601 if the file crosses borders.
7. Confirm the row count matches the source spreadsheet, minus any header row you intended.

Questions we get asked