How to Fix CSV Encoding Errors (Mojibake) in Excel

To fix CSV encoding errors in Excel, re-import the file with the correct encoding: in Data > Get Data > From Text/CSV, set the file origin to 65001: Unicode (UTF-8), then load. If the file is already open with garbled characters, re-importing with UTF-8 is the fix — Find and Replace cannot reliably undo mojibake, because the same garbled sequence can come from more than one original character.

Mojibake is the garbled text you see when a file is read with the wrong character encoding: Café becomes Café, £100 becomes £100, and naïve becomes naïve. The data is not corrupt — the bytes are intact. Excel is simply decoding them with the wrong map.

What Encoding Is, in Plain Language

A text file stores characters as bytes. An encoding is the map that says which bytes mean which characters. Two maps matter for CSV files:

• UTF-8: The modern standard. It can represent every character in every language, using one byte for plain ASCII letters and two or more bytes for accented characters, symbols, and non-Latin scripts. Most modern tools export UTF-8.
• Windows-1252 / ANSI: An older single-byte map used by default on many Windows systems. It covers Western European characters but cannot represent characters outside its set. When Excel on Windows opens a CSV without encoding information, it often assumes this map.

When a UTF-8 file is read with the Windows-1252 map, each multi-byte UTF-8 character is decoded as two or three separate Windows-1252 characters. That is mojibake: the bytes are correct, the map is wrong.

A CSV file does not record its own encoding. Excel has to guess, and the guess is often wrong — especially when the file was created on a different system, exported from a web tool, or downloaded from a platform that uses UTF-8 while Excel defaults to ANSI.

Recognizing Mojibake: Common Symptom Patterns

Mojibake has recognizable fingerprints. If you see these patterns, the file is almost certainly UTF-8 being read as Windows-1252:

A single garbled character tells you the encoding is wrong. A whole column of them confirms it. If instead you see ? or empty boxes, the file may have been saved in an encoding that cannot represent those characters at all — that is a different problem (character loss at save time), and re-importing with UTF-8 will not restore the lost characters.

Diagnose First: Which Encoding Is the File?

Before fixing, confirm the diagnosis:

1. Open the CSV in a plain text editor such as Notepad (Windows) or TextEdit in plain-text mode (Mac). If the characters look correct there, the file is fine and Excel's import guess is the problem.
2. Check for a BOM. A byte order mark (BOM) is a small invisible prefix at the start of a UTF-8 file that tells programs the file is UTF-8. In Notepad, a UTF-8 file with a BOM opens correctly; a UTF-8 file without a BOM may still open correctly in Notepad but fail in Excel, because Excel's default guess differs.
3. Look at the pattern. If é appears wherever é should be, the file is UTF-8 read as Windows-1252. If the garbled text looks different — for example, é (double mojibake, where the file was mojibake-corrupted and then re-saved) — the file itself may have been damaged by an earlier bad conversion, and fixing it takes more care.
4. Check the source. If the CSV came from a web export, a Mac, or a Linux system, it is almost certainly UTF-8. If it came from an old Windows program, it may genuinely be Windows-1252, and forcing UTF-8 would make it worse.

Most CSV encoding problems are the first case: a good UTF-8 file misread by Excel.

Method 1: Get Data Import With UTF-8 (Best Fix)

Re-importing with the encoding set explicitly is the cleanest fix.

Step-by-Step: Get Data Import

1. Start with a blank workbook. Do not open the CSV directly.
2. Open Get Data. Go to Data > Get Data > From File > From Text/CSV and select your CSV file.
3. Set the file origin. In the preview dialog, find the File Origin dropdown and set it to 65001: Unicode (UTF-8). The preview should immediately show the characters correctly — Café, £100, naïve.
4. Check the delimiter. While you are here, confirm the separator is correct. A misread delimiter can compound the problem — the guide to opening a semicolon-delimiter CSV covers delimiter fixes.
5. Load. Click Load (or Transform Data first if you also need to set column types, such as Text for ID columns — see the guide to fixing scientific notation).

Step-by-Step: Legacy Text Import Wizard

In older Excel versions, or when you prefer the classic wizard:

1. Open a blank workbook and go to Data > From Text/CSV (or Data > Get External Data > From Text).
2. Select the file and step through the wizard.
3. In step 1, set the file origin. Choose 65001: Unicode (UTF-8) from the File Origin dropdown. The preview should show correct characters.
4. Finish and load. The characters arrive correctly.

The file-origin setting is the entire fix. Everything else in the import can stay the same.

Method 2: Power Query Encoding on an Existing Import

If you already imported the CSV through Power Query, you can change the encoding without starting over:

1. Open the query. Go to Data > Queries & Connections, right-click the query, and choose Edit.
2. Change the source encoding. In the Applied Steps pane, click the Source step, then change the encoding setting to UTF-8 (65001).
3. Refresh. Click Close & Load. The characters reload correctly.

Power Query remembers the encoding step, so future refreshes with a new CSV in the same format will apply UTF-8 automatically. For a recurring export, this is the most maintainable fix.

Method 3: Convert the File to UTF-8 With BOM Before Opening

If you need the CSV to open correctly even when double-clicked — for example, you are sending it to colleagues who will open it directly — save it as UTF-8 with BOM. The BOM tells Excel the file is UTF-8, so the default guess becomes correct.

With Notepad (Windows)

1. Open the CSV in Notepad.
2. Go to File > Save As.
3. Set the encoding dropdown to "UTF-8 with BOM" (or "UTF-8" — in current Windows Notepad, UTF-8 saves with a BOM by default).
4. Save and replace the file.

With a Text Editor on Mac or Linux

Use your editor's Save As or encoding menu to save as "UTF-8 with BOM". In many editors this is an explicit option; in others, UTF-8 always includes the BOM. Verify by reopening the file in Excel: the characters should now display correctly on a plain double-click.

Note: the BOM is invisible and harmless for Excel, but some other tools (older database loaders, some scripts) may treat it as data. If your CSV feeds an automated system as well as Excel, test that system after adding the BOM.

Method 4: LibreOffice Calc Character Set

If you use LibreOffice Calc, its Text Import dialog handles encoding transparently:

1. Open the CSV in Calc. The Text Import dialog appears.
2. Set the Character Set to Unicode (UTF-8).
3. Check the preview — accented characters should display correctly.
4. Click OK, then save as .xlsx if you need Excel format.

LibreOffice defaults to UTF-8 more often than Excel does, which is why a file that looks garbled in Excel sometimes opens correctly in Calc. If you are converting without Excel at all, the guide to converting CSV to Excel without Excel covers the Calc route in detail.

Why Find and Replace Does Not Fix Mojibake

It is tempting to fix é by replacing it with é. Do not do this as a general fix:

• One garbled sequence can come from several originals. The mapping is not always one-to-one, especially for double mojibake.
• You will miss cases. Mojibake affects every non-ASCII character in the file. A handful of replacements will leave others behind.
• It does not fix the cause. The next import of a similar file will have the same problem.

Re-importing with the correct encoding fixes every character in the file at once, because it applies the right map to the whole file. Use Find and Replace only as a last resort for a tiny number of cells in a file whose original encoding is unknown.

Preventing Encoding Errors on Future Files

• Export as UTF-8 with BOM when you control the export. The BOM makes Excel's default guess correct.
• Always import deliberately. Double-clicking a CSV lets Excel guess the encoding. A deliberate import through Get Data lets you set it.
• Agree on UTF-8 with partners. If you regularly exchange CSV files, agree that all exports are UTF-8. Document it once and the problem largely disappears.
• Keep the original file. If a conversion damages the encoding, the original CSV is the only reliable source for a clean re-import.

Comparison Table: Which Encoding Fix Should You Use?

Setting the encoding at import time is the fix. The BOM route is for files that must survive double-clicking by other people.

Common Mistakes With CSV Encoding

Assuming the File Is Corrupt

Mojibake looks like corruption, but the bytes are usually intact. Do not delete, re-download, or re-export the file until you have tried a UTF-8 import — the fix is often one dropdown.

Saving a Mojibake File as CSV

If you open a mojibake file and save it as CSV without fixing the encoding, Excel may write the garbled characters back to the file, turning a reversible misreading into permanent damage (double mojibake). Always fix the encoding first, verify the characters, and only then save.

Mixing Encodings in One File

If a file was assembled from parts in different encodings — for example, one export pasted into another — no single encoding setting will fix every row. In that case, fix the parts separately and re-combine them after conversion.

Forgetting the BOM Trade-Off

The BOM helps Excel but can confuse some automated loaders. If your CSV feeds both Excel users and a script or database loader, test the loader after adding the BOM.

Frequently Asked Questions

Why does my CSV show é instead of é in Excel?

Because the file is UTF-8 and Excel read it as Windows-1252 (ANSI). The UTF-8 bytes for é were decoded with the wrong map, producing two characters instead of one. Re-import with File Origin set to 65001: Unicode (UTF-8) to fix it.

What is mojibake?

Mojibake is garbled text caused by reading a file with the wrong character encoding. The bytes are intact, but the decoding map is wrong, so characters display as unrelated symbols. It is fully reversible by re-reading the file with the correct encoding — unless the garbled text was saved back to the file, which can make it permanent.

How do I know if a CSV is UTF-8 or ANSI?

Open it in a plain text editor: if accented characters look correct there, the file is likely UTF-8 and Excel guessed wrong. If the file came from a web export, a Mac, or a Linux system, it is almost certainly UTF-8. If it came from an old Windows program, it may genuinely be ANSI — in that case, import with Windows-1252 instead of UTF-8.

Will saving as UTF-8 with BOM fix the file for everyone?

It fixes Excel's default guess, because the BOM tells Excel the file is UTF-8. Most other modern tools also handle the BOM correctly. A few older automated loaders may treat the BOM as data, so test those systems after adding it.

Can mojibake be fixed with Find and Replace?

Not reliably. The mapping from garbled sequences to original characters is not always one-to-one, and you will miss cases. Re-import with the correct encoding instead — it fixes every character in the file at once.

Final Checklist

Before you share a file with fixed encoding, run through this short checklist:

• Accented characters, currency symbols, and curly quotes display correctly.
• No Ã, Â, or â sequences remain in text columns.
• The fix was applied by re-importing with UTF-8, not by Find and Replace.
• The original CSV is saved as a backup before any re-save.
• If the file was saved with a BOM, downstream loaders were tested.
• Future exports will use UTF-8, and future imports will set the encoding explicitly.
• Dates, numbers, and ID columns were also checked during the re-import.

If all seven checks pass, your text is readable again — and the next import will not garble it.