Why Your CSV Looks Wrong in Excel: UTF-8, BOM, and Mojibake
Mojibake is not random corruption. It is a specific, recognisable failure: bytes written as UTF-8 and read as something else. The pattern it leaves behind tells you exactly that, which is more useful than it first appears.
The short answer
The file is UTF-8 and something opened it as a single-byte encoding, usually Windows-1252. UTF-8 stores an accented letter as two bytes; read one byte at a time, those become two visible characters — which is why José appears as José.
Nothing is corrupted in the file. The bytes are correct and were read wrongly, so the fix is to open it again with the encoding stated explicitly rather than to repair the text you are looking at.
What mojibake actually looks like
| Intended | Displayed | Why |
|---|---|---|
| José | José | é is two bytes in UTF-8; each is shown separately. |
| Köln | Köln | Same mechanism for ö. |
| café | café | The à is the giveaway — it rarely appears legitimately. |
A capital à immediately before an accented character is the signature. It almost never occurs in real text, so seeing it is close to proof of the diagnosis rather than a hint.
The  in the first column
The most useful single clue. A UTF-8 file often begins with a byte order mark — an invisible marker saying “this is UTF-8”. Decoded correctly it disappears:
name,city -> header: "name"Measured: when the file is decoded correctly, a leading byte order mark is removed rather than becoming part of the first header.
Decoded as Windows-1252, the same three bytes become visible characters — and because they are no longer a byte order mark, nothing strips them:
name,city -> header: "name"Measured: a UTF-8 file that begins with a byte order mark and is read as Windows-1252 shows  at the very start, and because it is no longer a real byte order mark it is not stripped — it ends up inside the first column name.
This is why a lookup on the first column suddenly fails, or a header match stops working for one column only. The name is not name any more.
Why it cannot simply be undone
Reversing mojibake needs the original bytes. Once the text has been decoded wrongly and pasted somewhere as characters, that information is gone — a browser tool receives the already-damaged characters, not the file. Some cases can be reversed by re-encoding, but it is unreliable and silently destructive when the guess is wrong, so this tool does not attempt it.
Practically: go back to the original file. Re-downloading and opening it with the encoding set is quick and certain, and guessing at a reversal is neither.
Diagnosing and fixing it
- 1. Check the first column name for If it is there, the file is UTF-8 and something read it as a single-byte encoding. That one detail identifies both the cause and the direction of the mistake.
- 2. Look for Ã, Â, and †sequences in the valuesThese are the visible shape of UTF-8 bytes shown one at a time. à before an accented letter is the most common signature.
- 3. Go back to the original file, not the damaged textOnce the wrong characters have been produced and copied, the original bytes are gone. Re-open or re-download the source and open it correctly instead.
- 4. Open it with an explicit encodingExcel’s Data → Get Data → From Text/CSV and Google Sheets’ File → Import both let you choose the file origin or encoding. Double-clicking does not.
- 5. If you produce the file, write a BOM for spreadsheet usersA UTF-8 byte order mark is how a spreadsheet is most reliably told the file is UTF-8. It is a pragmatic choice for that audience, not a requirement of the format.
Check the file
Pasting the file into the CSV Converter shows the column names and values as they parse. If the accents are intact there, the file is fine and the problem is in how your spreadsheet opened it. If  or à sequences appear, the damage happened before the text reached the tool.
It cannot detect or repair an encoding. Pasted text is already characters, not bytes, so the information needed to identify the original encoding is not there — and it does not guess. Conversion runs in your browser, so a file with real data is not uploaded anywhere.
Different symptoms, different causes
If the characters are correct but every row lands in one column, that is a delimiter problem — CSV opens in one column. If the characters are correct but zeros vanished or an ID became scientific notation, that is type conversion — Excel is changing your CSV data.
Measured with
- DataToolsHQ CSV Converter —
Papa Parse 5.5.4
The byte order mark behaviour and the mojibake examples were produced by running the text through the tool. Spreadsheet import behaviour is described from documentation and common practice rather than measured here.