How to Keep Special Characters and Symbols When Converting CSV to Excel

To keep special characters when converting CSV to Excel, import the file with the correct encoding (usually UTF-8) instead of double-clicking it — then check that the font supports the characters. Currency symbols (€, £, ¥), accented letters (é, ü, ñ), degree and trademark signs (°, ™), and entire non-Latin scripts (Arabic, Chinese, Hindi) all survive the trip when the encoding is right, and all turn into boxes, question marks, or gibberish when it is wrong. (For a quick conversion without settings to get wrong, the free CSV to Excel converter handles UTF-8 files correctly.)

This is the number-one cause of "my data looks corrupted" complaints after a CSV import, and it is almost never actual corruption — it is an encoding mismatch, which is fixable in under a minute.

Why Special Characters Break

A CSV is plain text with no formatting and, crucially, no reliable label saying which encoding it uses. Excel has to guess. When it guesses UTF-8 for a file that is actually Windows-1252 (or the reverse), every byte above 127 renders as the wrong character:

• é becomes é
• £ becomes £
• – (en dash) becomes â€"
• Whole non-Latin scripts become unreadable blocks

The data is still there; Excel is just reading the bytes with the wrong map. Re-importing with the right encoding restores everything — no data is lost. The deep version of this problem is covered in the guide to fixing CSV encoding errors in Excel.

Method 1: Import with the Right Encoding (Fixes 95% of Cases)

1. Open Excel to a blank workbook. Go to Data > From Text/CSV (or Data > Get Data > From Text/CSV on Mac).
2. Select the file. In the preview, look at the special characters first — ignore the numbers and layout for a moment.
3. Change File Origin until the characters look right. Try in this order: UTF-8 (65001), Windows-1252 (1252), then your regional default. The preview updates live, so you can see the moment it clicks.
4. Click Load, then save as .xlsx.

The single most common real-world case: a European colleague sends a Windows-1252 file, your Excel assumes UTF-8, and every € and é breaks. Setting File Origin to 1252 fixes the entire sheet at once.

Method 2: Convert the File to UTF-8 First

If you control the source, eliminate the problem permanently:

• In a text editor: open the CSV in Notepad++ or VS Code, check the current encoding in the status bar, and use "Convert to UTF-8" (not just "Save" — converting rewrites the bytes; saving keeps them).
• In Python: open('in.csv', encoding='cp1252') then write with encoding='utf-8-sig'. The -sig variant adds a byte-order mark that helps Excel auto-detect UTF-8 on double-click.
• Ask the exporter: many systems (databases, ERPs, web apps) let you choose the export encoding. UTF-8 should be the default choice for anything that crosses borders.

A UTF-8 file with a BOM double-clicks correctly in Excel on both Windows and Mac — the closest thing to a universal fix.

Character Types and What They Need

When Encoding Is Right but Characters Still Show as Boxes

If the encoding is correct and you still see □ boxes, the problem is the font, not the data. The character exists in the cell; the font just has no glyph for it. Select the range and switch to a font with broad coverage — Calibri handles Latin, Greek, and Cyrillic; for CJK text use a font like Microsoft YaHei or Yu Gothic; for Arabic, a font like Arial or Calibri works. The underlying value is fine — only the display was missing.

Special Cases Worth Knowing

The ₹ (rupee) problem. Older Windows-1252 files predate the rupee sign (added to Unicode in 2010). A ₹ in a 1252-encoded file may have been saved as "Rs." or as a private-use byte that nothing renders. If the symbol is missing entirely (not garbled), it was lost at export — re-export the source as UTF-8.

Degree and scientific symbols. °, µ, ±, ² survive UTF-8 fine but are often the first casualties of a 1252/UTF-8 mismatch because they sit in the contested byte range. If your lab or engineering data shows â° instead of °, it is the encoding, not the instrument.

Right-to-left scripts. Arabic and Hebrew import correctly as values under UTF-8, but Excel needs the cell's reading order set (Home > Alignment > right-to-left) to display them naturally. The characters are correct either way; only the visual order changes.

CSV vs Excel for symbol-heavy data. Once imported correctly, save as .xlsx immediately. A CSV cannot store the font choice or cell formatting that makes symbols readable — every reopen risks the same guessing game. The .xlsx locks in both the characters and their display.

FAQ

Why do my euro signs turn into € after importing a CSV?

Your file is Windows-1252 but Excel read it as UTF-8. Re-import with Data > From Text/CSV and set File Origin to 1252 — every € snaps back at once.

The characters are correct but show as empty boxes. Is the data lost?

No. The data is fine; the font lacks glyphs for those characters. Switch the range to a font with broader coverage (Calibri, Arial, or a script-specific font) and the characters appear.

How do I stop this happening every time I get the file?

Convert the source to UTF-8 with a BOM once (text editor or Python), or ask the sender to export UTF-8. A UTF-8-with-BOM file double-clicks correctly in Excel without any import dialog.

Do special characters survive saving back to CSV?

The characters survive if you save with UTF-8 encoding, but Excel's "CSV (Comma delimited)" save option writes in your regional encoding by default — which may drop characters outside that encoding. For symbol-heavy data, keep the .xlsx as the master and treat CSV as an export copy.

What about Chinese, Arabic, or Hindi text in CSVs?

Use UTF-8 end to end and a font that supports the script. Excel handles all Unicode scripts as cell values; display issues are font issues, and input direction (for RTL scripts) is a cell-formatting setting.

Final Checklist

• Imported with Data > From Text/CSV — encoding chosen by preview, not guessed by double-click.
• File Origin set so €, é, °, and non-Latin text all render correctly in the preview.
• Font checked: no □ boxes; script-specific font applied where needed.
• Source converted to UTF-8 (with BOM) where possible, so future imports need no dialog.
• Saved as .xlsx so characters, fonts, and formatting are locked in.

If all five checks pass, every symbol in your CSV now displays exactly as written — no boxes, no question marks, no mojibake.