Why Your CSV Shows Weird Characters in Excel, and How to Fix the Encoding (2026 Guide)

Diagnose it in 30 seconds: your data is not damaged, it is misread

The first thing to establish when a CSV opens with weird characters is whether the data is damaged or only displayed wrong, because the two cases have very different fixes, and the wrong fix can turn a display problem into real data loss. Here is the 30-second test. Open the same file in a plain text editor, Notepad on Windows or TextEdit in plain-text mode on a Mac, or in Google Sheets through File, then Import. If the characters look correct there, your data is intact and only Excel display is wrong. The file on disk holds the right bytes, and Excel is simply decoding them with the wrong encoding. That is the common case, and every fix in this guide starts from it.

The second clue is which characters are wrong. If plain English text, numbers, and punctuation look fine, but accented letters, umlauts, cedillas, the euro sign, and non-Latin scripts look wrong, you are looking at an encoding mismatch, not a delimiter problem and not corruption. A delimiter problem puts whole rows in one column. Corruption scrambles everything or drops rows. An encoding problem is surgical: it breaks exactly the characters that need more than one byte in UTF-8, and leaves everything else untouched. If your file shows José where it should show José, or München where it should show München, that pattern is the fingerprint of UTF-8 bytes read as a legacy single-byte encoding, and it tells you both the cause and the fix.

The third check decides whether rescue is still possible. If the mangled characters are visible in the text editor too, the file itself may have been re-saved after the misreading, and the wrong characters may now be written into the file. Do not panic yet, and above all do not save over the original again. The rescue section later in this guide covers exactly this case, including the one situation where the characters are truly unrecoverable: when a character was replaced by a question mark or a replacement symbol during a save, the original information is gone from that copy, and only the source data can regenerate it. Until you have checked, keep the original file untouched, work on a copy, and never save a mangled file back over the good one.

Why Excel guesses wrong: a CSV file carries no encoding label

To understand why this keeps happening, you need one fact about the CSV format: a CSV file is plain text with no header that says which encoding it uses. A spreadsheet file carries its structure and its text encoding with it. A CSV file carries neither. It is just bytes, commas, and line breaks. When a program opens it, the program must decide how to turn those bytes into characters, and different programs decide differently. Modern text editors and Google Sheets detect UTF-8 automatically in most cases, which is why the same file looks correct in them. Excel, when you double-click a CSV file, does not detect. It assumes your system default encoding, which on many Windows systems is a legacy code page such as Windows-1252, and it does not check whether that guess was right.

That assumption is the whole problem. UTF-8 represents a character like é as two bytes, and a character like € as three bytes. A legacy single-byte encoding reads each byte as one character of its own, so one é becomes two wrong characters, é, and one € becomes three, €. The file did not change. The reader changed the meaning of the bytes. This is also why the problem follows a pattern by region and by machine. A colleague on a system whose default encoding matches the file sees it correctly, while you see garble, and the same file can look fine on one computer and broken on another. Neither computer is broken, and the file is not corrupt. The two readers simply disagree about what the bytes mean, and Excel on double-click trusts its own default without asking.

It also explains why this problem appears so often with files converted from JSON. JSON is UTF-8 by definition, so a JSON-to-CSV conversion naturally produces a UTF-8 CSV, including every accented name, city, and currency symbol in the source data. The conversion is correct. The opening is mismatched. The converter on this page, for example, downloads plain UTF-8 with no byte-order mark, which is the correct choice for web uploads, databases, Google Sheets, and Python, but it means a Windows Excel double-click may guess the wrong encoding. Knowing that the mismatch sits at the opening step, not the conversion step, tells you where to fix it: at the import, or with a BOM, as the next sections show.

Read the garble: what the weird characters tell you

Mangled text is not random, and learning to read it tells you the original character and confirms the diagnosis before you touch anything. The signature pattern is à followed by another character. Whenever you see é, ä, ü, or ç, you are looking at a UTF-8 character that was read as Windows-1252. The à is the first byte of the UTF-8 sequence, misread as its own character, and the second character is the second byte, also misread. Once you know the pattern, you can decode the garble in your head: é was é, ü was ü, ç was ç, ão was ão, as in São Paulo showing up as São Paulo. The euro sign is the most dramatic case: € is three bytes in UTF-8, so it shows up as the three characters €. An em dash shows up as â€, and a curly apostrophe shows up as ’.

The pattern changes with the script, and that change is diagnostic too. Latin-script names produce the à pattern above. Japanese, Korean, and other non-Latin scripts produce longer garble, because each character is three bytes in UTF-8, so one character becomes three wrong ones: Tokyo written as 東京 shows up as a run of characters like æ±äº¬, and a Korean name becomes a similar run. If you see that kind of long garble, the diagnosis is the same, UTF-8 read as a single-byte encoding, only the characters involved are three-byte ones. If instead you see question marks or black diamond replacement symbols where characters should be, the diagnosis is different: those symbols mean information was already lost during a save, not merely misread during display, and the rescue section covers what to do then.

The code block below shows the exact misreadings, produced by taking correct UTF-8 text and decoding it as Windows-1252, the way Excel does on double-click. These are not invented examples. Each pair was generated mechanically, so you can match your own file against them and confirm the diagnosis before fixing anything. If your file shows the left side of one of these pairs where it should show the right side, you have an encoding mismatch, and the import fix in the next section will repair the display without changing the file.

Correct text  ->  What Excel shows\nJosé García  ->  José GarcÃ\u00ada\nMünchen      ->  München\nFrançois     ->  François\nSão Paulo    ->  São Paulo\n€50,000      ->  €50,000\ncafé — ok    ->  café — ok\n東京 (Tokyo)  ->  æ\u00b1京\n김민준        ->  김민준

Notice what the table proves: nothing is missing. Every wrong character corresponds to a real byte of the original, just decoded with the wrong table. That is why the import fix works so completely. When you tell Excel the file is UTF-8, it decodes the same bytes with the right table, and every character snaps back to itself, with no editing, no find-and-replace, and no data entry. If your file matches this pattern, skip the rescue section and go straight to the import fix. You do not have a damaged file. You have a misread one.

Fix 1: import the file and tell Excel it is UTF-8

This is the fix to try first, because it changes nothing about your system, nothing about the file, and it works on any UTF-8 CSV whatever its delimiter. Instead of double-clicking the file, open Excel first, then import the file through the guided import, where you choose the encoding yourself. The preview in the import dialog shows you immediately whether you picked right: the characters display correctly in the preview exactly as they will on the sheet. If the preview still shows garble, you have not changed anything yet, and you can try another file origin before loading.

• ▸In Excel, go to Data, then From Text/CSV, and select your file.
• ▸In the preview dialog, set the file origin to 65001: Unicode (UTF-8). On older Excel versions the same option appears as Unicode (UTF-8) in the Text Import Wizard.
• ▸Check the preview. If the characters now read correctly, continue. If they still look wrong, the file may not be UTF-8 at all, so try the other origins in the list one at a time and watch the preview.
• ▸Set the delimiter to the character the file uses, comma, semicolon, tab, or pipe, and check that the columns split correctly in the same preview.
• ▸Click Load. For columns that must stay as text, like codes with leading zeros, set those columns to Text in the import step, before loading.

Make this your default way of opening CSV files, not just your rescue move. Double-clicking is a guess about both the delimiter and the encoding. Importing is a choice about both, and the choice takes about ten seconds longer. The same fix works on a Mac, where the import route is also the reliable one: open a blank workbook, go to Data, then From Text, pick the file, choose Unicode (UTF-8) as the file origin, and finish. Google Sheets needs no fix at all in most cases, because File, then Import detects UTF-8 automatically, which is why a file that looks broken in Excel often looks perfect in Sheets. That difference is itself a diagnosis: if Sheets shows it right and Excel shows it wrong, the file is fine and Excel guessed wrong.

Fix 2: add a BOM so double-clicking works

If you open the same kind of file every day, importing each time gets old, and the durable fix is to give Excel the hint it needs on double-click. That hint is a BOM, a byte-order mark: three invisible bytes at the very start of the file that say this file is UTF-8. Excel checks for a BOM before guessing, so a UTF-8 file with a BOM opens correctly on double-click even on a Windows system whose default encoding is Windows-1252. The BOM is invisible in Excel and in most editors, and it does not change any data row. It only affects the first three bytes of the file.

The easiest way to add one needs no code. Open the file in Notepad, go to File, then Save As, and set the encoding dropdown to UTF-8 with BOM, then save. The file now opens correctly on double-click in Excel. If you produce files from a script, add the BOM at write time instead of patching files afterwards. In Python, that is one word: open the file with encoding utf-8-sig instead of utf-8, and Python writes the BOM for you. The snippet below shows it, and the bytes it produces were verified: the file starts with the three BOM bytes, followed by the data in plain UTF-8.

with open("customers.csv", "w", encoding="utf-8-sig", newline="") as f:\n    f.write("name,city\n")\n    f.write("José García,München\n")\n# First bytes of the file: EF BB BF, then the UTF-8 data.\n# Excel now opens it correctly on double-click.

Two cautions before you add a BOM everywhere. First, some tools treat a BOM as data, not as a marker. A strict CSV parser may read the first header as BOM plus name instead of name, which breaks a header lookup. The converter on this page deliberately downloads without a BOM for exactly this reason: plain UTF-8 is correct for web uploads, databases, and Python, and the BOM is only an Excel double-click convenience. So add a BOM to copies meant for Excel, not to the master file that feeds other tools. Second, a BOM does not repair a file that is not UTF-8. If the file was written in Windows-1252, adding a BOM on top of it makes things worse, because Excel will then decode single-byte data as UTF-8 and produce new garble. Add a BOM only to a file you know is UTF-8, which you can confirm with the text-editor test from the diagnosis section.

Rescue a file that already looks mangled

So far every fix has assumed the file on disk is still correct and only the display is wrong. But sometimes the mangled version has already been saved, and the question becomes whether the original characters can still be recovered from the saved copy. The answer depends on exactly what the save did, and there are two cases to tell apart. In the first case, the file on disk still holds the original UTF-8 bytes, and only Excel display is wrong. That is the case the text-editor test detects: the editor shows the characters correctly, so nothing is lost, and Fix 1 repairs the display. In the second case, the file on disk now contains the wrong characters themselves, because someone opened it in Excel, saw the garble, and saved it back to CSV, writing the misread characters into the file.

The second case is often still recoverable, and the test is whether the garble follows the à pattern from the decoder section. If the saved file literally contains the characters é where é should be, the recovery is a re-encode: read the file as if it were Windows-1252, which recovers the original UTF-8 bytes, then decode those bytes as UTF-8, which recovers the original characters. The snippet below does exactly that, and it was verified on a real file: a name written as José, misread as José, came back as José after the round trip, byte for byte. Work on a copy, never on the only version, and check the result in a text editor before opening it in Excel again.

with open("mangled.csv", "r", encoding="cp1252") as f:\n    text = f.read()\n# Encode back to the bytes Excel misread, then decode as UTF-8.\nfixed = text.encode("cp1252").decode("utf-8")\nwith open("fixed.csv", "w", encoding="utf-8") as f:\n    f.write(fixed)\n# Verified: José -> José, München -> München.

The re-encode trick has one hard limit, and it is important to respect it. It works only when the misread characters survived the save intact, as é and its companions. If the save replaced characters with question marks, or with the black diamond replacement symbol, the original information is gone from that copy. No decoding can recover a character that was replaced by a placeholder, because the placeholder carries no information about which character it replaced. In that case, stop repairing the copy and regenerate the file from its source: re-export it from the database, the tool, or the JSON it came from, and this time open it with Fix 1 or give it a BOM with Fix 2. And whatever you do, keep the damaged copy aside until the regenerated file checks out. Deleting the only copy before verifying the replacement is how a recoverable problem becomes a lost dataset.

What this means for files from this page converter

The converter on this page produces exactly the kind of file this guide is about, so it is worth stating its behavior plainly. The download is plain UTF-8 with no BOM. That was verified against the real code, not assumed: the download creates a text/csv Blob with charset=utf-8 and writes no leading mark, and the conversion engine itself was run on a sample holding José García, München, François, Łódź, São Paulo, a euro amount, Tokyo in Japanese, and Korean names, and produced every character byte-identically, with no BOM at the start of the output. So if your converted file shows weird characters in Excel, the conversion did not damage anything. The file is correct UTF-8, and Excel guessed the wrong encoding on double-click.

That gives you two clean options for converted files. The first is the import route: open the downloaded file with Data, then From Text/CSV, set the file origin to 65001: Unicode (UTF-8), and load. The characters will read correctly, and you have changed nothing about the file, so it stays valid for every other tool. The second is the BOM route: open the downloaded file in Notepad, save it as UTF-8 with BOM, and keep that copy for Excel, while keeping the original download for anything else. Do not re-convert the data to fix an encoding display problem, and do not paste the converted output through a spreadsheet and save it back, because that round trip can introduce exactly the delimiter and encoding mismatches this guide exists to prevent. Fix the opening, not the data.

One more converter detail matters here. The converter lets you choose the delimiter before downloading, and that choice is independent of encoding. A file can have the right delimiter and the wrong encoding display at the same time, or the right encoding and the wrong delimiter, or both wrong at once. If your converted file opens in one column and the characters look wrong, fix both settings in the same import: pick the delimiter you chose at conversion time, and set the file origin to 65001. The companion guide on the one-column problem covers the delimiter half in detail, and it is linked in the related guides below.

Prevention checklist: export it right so nobody has to fix it

Encoding problems are a mismatch between writer and reader, so prevention means making the writer declare what it wrote, in a way the reader will honor. Run through this checklist when you produce a CSV, and the next person who opens it will not need this guide. First, know your encoding at export time. If your data holds anything beyond plain ASCII, export as UTF-8, and say so in the file name or in the note that travels with it, because a CSV file cannot say it for itself. Second, if the audience is Excel on Windows, add a BOM to the Excel copy, or export with the CSV UTF-8 format from Excel Save As, which writes a BOM for you. Third, if the file feeds other tools as well, keep a plain UTF-8 copy without a BOM for them, because some parsers treat a BOM as part of the first header.

Fourth, never save a rescued file back over the original until you have verified the rescue in a text editor. A save from Excel rewrites both the delimiter and the encoding with Excel own defaults, which can reintroduce the mismatch for the next reader, or turn a display problem into real data loss. Fifth, when you receive a file, open it in a text editor first if anything looks off, and confirm the encoding before you let any spreadsheet save over it. And sixth, keep the source data. A CSV is a flattened snapshot, not the data itself, so if a rescue goes wrong, the source lets you export again cleanly instead of repairing a damaged copy. Most encoding horror stories end with someone discovering too late that the damaged CSV was the only copy. Do not let that be your file.

Related guides

• Why Your CSV Opens in One Column in Excel, and How to Fix It (2026 Guide) →
• How Can I Convert a JSON File to a CSV File Online? (2026 Guide) →
• What Are Ways to Convert JSON to CSV Locally? 6 Methods, Compared (2026 Guide) →
• Why Excel Drops the Leading Zeros From Your CSV Codes, and How to Keep Them (2026 Guide) →
• Why Excel Changes Your CSV Dates, and How to Keep Them (2026 Guide) →
• Why Saving Your CSV in Excel Changes It, and How to Keep the Original Safe (2026 Guide) →
• Why Excel Won't Open Your Big CSV File, and What to Do Instead (2026 Guide) →

Frequently asked questions