Home · Free tools · Weird characters in a CSV
Fix the weird characters in a CSV
The file is not corrupted. If you are seeing é, ü,
black diamonds with question marks, or a wall of symbols where names should be, it was
saved in one encoding and is being read in another. Drop the .csv here: the real encoding
is detected, the text comes back, and the export is always UTF-8.
Open the broken CSV
Drop a .csv or .txt here, or click to choose
Nothing is uploaded. The file is read by JavaScript in this tab and never leaves your computer — no server sees it, and closing the tab throws it away.
Fixing the characters in a CSV file
- Drop the file in. It is read by JavaScript in this tab. No server sees it, and closing the tab throws it away.
- Read what it detected. Above the table it says "Read as …". If the accents and names look right, that was the one.
- Export as UTF-8. Download .csv or .xlsx — the output is always UTF-8, so it does not break again downstream.
Why “José” becomes “José”
A CSV does not record the encoding it was written in. It is a run of bytes, and whoever
opens it has to guess. In UTF-8 an é takes two bytes; read those two bytes as
Windows-1252 and you get two characters, Ã and ©. Hence the
unmistakable pattern: Ã followed by something odd.
The other direction gives black diamonds with question marks (�):
the file was Windows-1252, Shift-JIS, Big5 or EUC-KR, and something is reading it as UTF-8.
How the detection works here
- If there is a BOM, the encoding is declared and there is nothing to guess.
- Without one, UTF-8 is tried in strict mode. Most files that are not UTF-8 fail that, which already rules a lot out.
- Among the survivors the decoded text is scored and the best one wins. Scoring counts runs of CJK characters, not isolated ones, and counts accented Latin letters as evidence too — that distinction was added on 2026-09-04 after a Spanish Windows-1252 file was being decoded as GBK, because a page of Western high bytes read as Chinese scores well under a naive "more CJK is better" rule.
- Windows-1252 is a full candidate, not a last resort.
You are the real check: if the names read correctly, it picked the right one.
Stopping Excel from breaking it again
On Windows, double-clicking a UTF-8 CSV with no BOM makes Excel read it in the system's regional encoding — and it breaks all over again. Two ways out:
- Download .xlsx instead of .csv. A workbook carries its encoding inside it.
- If it has to be CSV, open it through Data → Get Data → From Text/CSV and choose 65001 (UTF-8) in the dialog.
All in one column is a different problem
If the file opens with everything crammed into column A, that is the delimiter, not the encoding: in many European locales Excel expects a semicolon because the comma is the decimal separator. CSV to Excel detects the delimiter on its own.
Questions people ask
Does this change my data?
No. The same bytes are interpreted differently; not one character is modified. Leading zeros survive too.
What if the detection is wrong?
It happens on very short or almost entirely numeric files, where there is little to go on. The quickest fix is to ask for the file again as UTF-8 with a BOM.
Which encodings are tried?
UTF-8 and UTF-16 by BOM, then Shift-JIS, EUC-KR, Big5, GBK and Windows-1252 by strict decoding and scoring.
Is the file uploaded?
No. Open the developer tools, Network tab, and drop the file: not a single new request appears.
Related
Do this on your own machine instead
TableDI is a desktop spreadsheet workspace that runs entirely on your machine. Import the file, fix it, chart it — nothing is uploaded, and there is no account to create.
Free forever, not a trial — no account, no card. macOS today; a Windows build is in progress. What the paid tier adds.
Last reviewed 2026-09-01 by the TableDI team. Something wrong on this page? Tell us — it is one inbox, read by the people who build TableDI.