Why Your CSV Shows Garbled Characters in Excel — and How to Fix It

What went wrong: one file, two code books

A computer does not store letters. It stores numbers — bytes — and a character encoding is the code book that says which bytes stand for which letter. For plain English letters, digits and punctuation, nearly every code book agrees, which is why the column headings and numbers in a garbled file usually look fine. They disagree on everything else: accented letters, Korean, Japanese, Chinese, many currency symbols.

Imagine writing a note with one code book and handing it to someone holding a different one. They read every symbol faithfully and still get nonsense, because each symbol means something else in their book. The Korean word 한글, saved in the Korean code page, is four bytes. Read with the Western European code book, the same four bytes come out as four Latin letters, ÇѱÛ. Nothing in the file changed. Only the reading did.

Some real examples — each garbled version is exactly what those bytes turn into:

Two patterns are worth spotting. Pairs of letters starting with Ã in place of accented letters almost always mean a UTF-8 file read as Western European. Replacement marks — �, or ? in some programs — usually mean the opposite: a file in an older regional code page, read by a program that assumed UTF-8.

Why it happens with Excel so often

UTF-8 is the code book the web and most modern software use by default, and it covers every writing system at once. Excel on Windows, though, has long saved CSV files in the computer's legacy regional code page instead: EUC-KR(strictly, Microsoft's extension of it, CP949) on a Korean system, Shift_JIS on a Japanese one, GB18030 or GBK on a Chinese one, and Windows-1252 on a Western European or American one. A CSV file has nowhere to write down which code book it used, so the next program has to guess — and most guess UTF-8.

It goes wrong in the other direction too. A UTF-8 CSV from a website or database looks perfect everywhere except Excel: double-click it, and Excel often reads it with the local regional code page, producing café on a Western computer and 譚ｱ莠ｬ for 東京 on a Japanese one.

The exception is a UTF-8 file that begins with a byte-order mark (BOM): three invisible bytes, EF BB BF, at the very start of the file. They work as a label saying “this is UTF-8”, and Excel honours the label. That one small detail is the whole trick behind the fixes below.

Fix 1: repair it in your browser

1. 1
   Open the viewer. Go to pdfgami.com/csv-viewer. It accepts .csv, .tsv, .tab, .psv and .txt files. Nothing to install and no account.
2. 2
   Drop the garbled file. The viewer works out the encoding in this order:

   • If the file starts with a byte-order mark, it follows the mark: UTF-8, UTF-16 LE or UTF-16 BE.
   • Otherwise it tries strict UTF-8. Strict means a single invalid byte sequence counts as failure instead of being papered over with replacement marks, so when it succeeds the file really is UTF-8.
   • If strict UTF-8 fails, the viewer studies the shape of the bytes in the first 64 KB. Accented letters standing alone between ordinary letters point to Western European (Windows-1252). Korean, Japanese and Chinese characters take two bytes each and come in runs, and each code page uses different byte ranges: Japanese Shift_JIS regularly uses low values that Korean and Chinese avoid, and Korean syllables sit in a narrower band than Chinese characters.
   • It then checks the guess by decoding the sample strictly in that code page, moving to the next candidate if it fails. If nothing fits, the file is read as Western European (Windows-1252).

   When the file was not UTF-8, a notice above the table says so and names the encoding used.

3. 3
   Check the text, and override if needed. If anything still looks wrong, open the Encoding dropdown above the table and pick another: UTF-8, Korean (EUC-KR / CP949), Japanese (Shift_JIS), Chinese (GB18030 / GBK), Western European (Windows-1252), UTF-16 LE or UTF-16 BE. The table redraws immediately.
4. 4
   Download for Excel (UTF-8). This saves a copy — named after your file, ending .utf8.csv — encoded as UTF-8 with a byte-order mark. Because of that mark, Excel reads the characters correctly whether the computer is set up for Korean, Japanese, Chinese or English. Your original file is not touched.

One detail: the copy always separates fields with commas, even if the original used semicolons or tabs. Where Excel expects semicolons, a double-clicked comma file can land entirely in the first column; if so, use the import route in Fix 2 and choose the separator there.

Once the text reads correctly, the same page lets you sort, filter and inspect the columns. For a full tour of those features, see how to open a CSV file.

Fix 2: import it properly in Excel

To stay in Excel, do not double-click the file; import it, which lets you tell Excel which code book to use. Menu names and positions vary between Excel versions and between Windows and Mac, so look for these words rather than exact locations:

• Open a blank workbook and go to the Data tab. Choose From Text/CSV, or in older versions the From Text option that opens a text import wizard.
• Select the file. In the preview, find the setting called File Origin (or similar). Choose the UTF-8 entry for a UTF-8 file, or the regional one for a legacy file — they are listed by language and code page number, such as 949 for Korean, 932 for Japanese, 936 for Simplified Chinese and 1252 for Western European. The preview updates, and the right choice is the one where the text becomes readable.
• Check the separator in the same window, then load the data.

To stop the problem at the source, save from Excel with Save As and pick CSV UTF-8 (Comma delimited) rather than plain CSV (Comma delimited), if your version offers it. The UTF-8 option writes the byte-order mark, so the file opens correctly in Excel and everywhere else.

Fix 3: Google Sheets

Google Sheets reads UTF-8 CSV files well, so a UTF-8 file that is only garbled inside Excel will usually look right after File > Import. It is less dependable with legacy code pages, so a Korean or Japanese Excel export may still come out garbled. Worth knowing: importing into Sheets uploads the file to Google's servers and keeps it in your Google Drive — fine for a public dataset, worth a second thought for payroll or a customer list.

When no fix can work

The automatic guess can be wrong. It needs enough non-English text to judge by. A very short file, or one where only a handful of names use accents or Asian scripts, may not give it enough to go on and can be read in the wrong code page. That is what the Encoding dropdown is for: you can see the text, so you are the final judge.

The garbage may already be saved.If someone opened the file with the wrong encoding and then saved it, the junk itself became the file's contents, and every decoder, this one included, will faithfully show you that junk. Where characters were replaced with ? or �, the original bytes were discarded and nothing can recover them. The only real fix is the original file: export it again, or ask the sender to export it as CSV UTF-8.

More ways to read files without uploading them

The CSV viewer sits alongside a JSON viewer and a Markdown viewer in the file viewers section. All of them read the file in your browser tab, and none of them sends it anywhere.

Frequently asked questions