CSV Encoding and Mojibake: How to Fix Broken Text
Müller becomes Müller, café becomes café. Mojibake is the classic sign of a character-encoding mismatch — and it is preventable.
Every text file is a sequence of bytes, and those bytes only make sense under a specific character encoding. When the writer and the reader disagree about which encoding to use, the result is mojibake: the garbled characters that appear when an umlaut or an accent is decoded the wrong way.
This is not a cosmetic problem. In a data import, mojibake corrupts names, addresses and product descriptions, and it is notoriously hard to clean up after the fact. This guide explains the encodings, why Excel is the usual culprit, and how to detect and fix the problem reliably.
The encodings you will meet
Three encodings cover the vast majority of real-world CSV files:
- UTF-8 — the modern standard, supports all languages, the correct default.
- Latin-1 (ISO-8859-1) — an older Western-European encoding.
- Windows-1252 — Microsoft's superset of Latin-1, still common in Windows exports.
The three overlap for plain ASCII, which is why problems only surface the moment a file contains an accented character, an umlaut, a currency symbol or an em dash.
Why Excel ruins CSVs
Excel's CSV handling is the most common source of encoding pain. When you open a CSV directly, Excel frequently assumes a legacy Windows encoding rather than UTF-8, even though the file was saved as UTF-8. Accented characters then render as mojibake, and if the file is saved again, the corruption becomes permanent.
Worse, Excel has no reliable way to force UTF-8 on import. The safe workflow is to convert the data to a clean, well-formed format first, then import it explicitly.
How to detect mojibake
- Look for the tell-tale sequences:
ä,é,€. - Check whether the file was exported from Windows — that suggests Windows-1252.
- If the text is readable but accents are boxes or question marks, the encoding was lost or replaced.
The sequence ä is the classic fingerprint of UTF-8 bytes being displayed as Windows-1252. Recognising these patterns lets you reverse the damage.
Common encoding problems
| Problem | Typical cause | Fix |
|---|---|---|
| ä, ö, ü instead of umlauts | UTF-8 read as Windows-1252 | Re-decode as UTF-8 |
| € instead of € | UTF-8 read as Windows-1252 | Re-decode as UTF-8 |
| � replacement characters | Invalid bytes for the encoding | Detect actual encoding first |
| Boxes or blanks | Encoding lost during export | Re-export as UTF-8 |
Fixing it automatically
The reliable fix is to detect the file's actual encoding and convert it to UTF-8 in one step. The FormatFlash text-encoding converter does this in the browser, so the data never leaves your device — important when the file contains customer or employee data.
Prevention beats repair
Mojibake is far cheaper to prevent than to repair, because once a file is re-saved with the wrong encoding, the original bytes are gone. Standardise on UTF-8 for every export and import step, test with a sample that contains accented characters, and keep a converter on hand for the legacy files that arrive already broken. When the data is sensitive, run the fix locally so nothing leaves your network during cleanup.
Frequently asked questions
What is mojibake?
Mojibake is the garbled text you see when a file is decoded with the wrong character encoding, such as reading UTF-8 as Windows-1252. Characters like ä and é turn into ä and é.
Why does Excel break CSV encoding?
Excel often assumes a locale-specific legacy encoding when opening a CSV instead of UTF-8, so accented characters and special symbols get misread.
How do I fix mojibake automatically?
Detect the actual encoding of the source text and convert it to UTF-8. FormatFlash provides a text-encoding converter that does this in the browser.