Garbled CSV text in Excel: check encoding before saving over the original
By ON Lab · Sources checked November 8, 2026
If multilingual text looks wrong when a CSV opens in Excel, preserve the original file and import it with the correct encoding instead of saving over the garbled view. Microsoft documents Data → Get Data → From File → From Text/CSV and the text-import route for UTF-8 files. Its current guidance also states that a UTF-8 CSV with a BOM can be opened normally.
Encoding, delimiters and column types are separate choices. Fixing one does not prove the others are correct. The reader question behind this guide concerns multilingual UTF-8 exports that Excel did not display as intended. We checked current Microsoft documentation and tested a small file's actual encoding bytes; we did not reproduce an Excel import in a local application.
Keep the original before trying a repair
Work from an unchanged source CSV. If an opened sheet looks garbled, avoid saving that view over your only copy. A wrong display caused by decoding and characters already lost during an earlier export are different situations.
| Observation | Inspect next | Do not conclude yet |
|---|---|---|
| Accented or non-English text becomes unexpected character sequences | The file's actual encoding and import encoding choice | That changing the font repairs the bytes |
| Every record appears in one column | The selected delimiter in the import preview | That the problem is necessarily UTF-8 |
| Text is readable but identifier zeros disappear | Column type interpretation | That decoding alone preserved all values |
| The original file already contains literal question marks instead of letters | The source export and an earlier intact copy | That adding a BOM can restore the lost letters |
Choose one row with known text and one row with a value whose exact representation matters. Keep both available for the final comparison.
Use the import preview deliberately
- Open Excel and start the documented text/CSV import route rather than relying on the file association.
- Select the unchanged original file.
- Inspect the encoding or File Origin choice in the import interface. Use UTF-8 when that is the file's actual encoding; do not assume every CSV uses it.
- Inspect the delimiter independently and confirm that headers and fields occupy the intended columns.
- Check representative multilingual text in the preview before loading.
- Review column types for identifiers or other fields that should remain text, then load the intended result.
The exact route varies with Excel version and available import tools. Microsoft's current UTF-8 help lists the Power Query text/CSV route and Get Data From Text. Its Text Import Wizard documentation explains File Origin and delimiter choices for that interface. Record the version and route you used if the available controls differ.
If the preview still shows the wrong characters after choosing the expected encoding, stop and verify the source. Repeatedly loading and saving a bad interpretation is not a new test. Ask the export owner for the actual encoding and a known intended sample when that information is missing.
What a BOM does, and what our byte test established
A UTF-8 BOM is a marker at the beginning of a file. In our local fixture, the same two-column CSV was saved once as UTF-8 and once as UTF-8 with the marker. The second file began with the bytes EF BB BF. Decoding each file correctly produced the same original text.
We used a synthetic name and city containing accented letters. Deliberately decoding the UTF-8 bytes as a different character encoding produced different text. A CSV parser using the correctly decoded text recovered the expected two columns and rows. That demonstrates the byte-versus-decoding distinction; it is not an Excel UI result.
Microsoft's current guidance says UTF-8 files saved with a BOM can be opened normally in Excel. This is useful when preparing an export for that receiving workflow. It is not proof that every historical Excel build or every other CSV consumer handles a marker identically. Follow the receiving system's file requirements and retain a representative import check.
Verify the loaded and saved result
After loading, compare the exact sample text, row count and column boundaries with the source. Inspect the fields whose type matters. A readable city name does not prove that an account code, date or long identifier survived interpretation unchanged.
Save the working result under a new appropriate filename, reopen it and compare the same samples again. If you must export another CSV for a downstream system, verify that system's required encoding and delimiter and inspect the exported copy. A successful save does not prove that another application will decode it the same way.
For identifier preservation, use the leading-zero and CSV opening guide. This article addresses text decoding; it does not replace a column-type review.
When the original characters are already gone
If an earlier export replaced characters with literal question marks or saved the wrong decoded text into the file, a marker alone cannot recreate the intended text. Return to the original data or another intact export. Do not describe a fresh import setting as a recovery method for information that is no longer present.
Keep the diagnosis specific: original bytes, chosen encoding, delimiter, column types, and the exact point where the result diverges. That record is more useful than labeling every unusual CSV display “corruption,” and it avoids changing unrelated workbook settings without evidence.