Fix Text Encoding

Recover text mangled by the wrong encoding — the é and Ø£ garbage that CSV exports produce.

Processed on your device — no upload

termiva fix-encoding data.csv
0 chars

Paste the mangled text. The repaired version appears here, with what went wrong named.

mode repair mojibakedetected changed nothing uploaded

How to use it

  1. Paste the mangled text, or choose the original file.
  2. Pick which kind of damage it is.
  3. Compare the two boxes, then download the repaired text.

How it works

Mojibake is text that was written as UTF-8 and then read as if it were a single-byte encoding. The bytes are intact; only the interpretation was wrong. That is why it can be repaired at all — nothing was lost, it was merely misread.

The repair reverses the mistake. Each character is turned back into the byte it stood for, and those bytes are then decoded as UTF-8 properly. Café becomes Café; أحمد becomes أحمد.

The safeguards matter more than the arithmetic. Decoding is done in strict mode, so an invalid byte sequence throws rather than producing replacement characters that would look like a successful fix. And text containing a character that could not have come from a single-byte decode is recognised as not being mojibake at all and returned untouched — repairing correct text would destroy it.

The second mode handles a different failure: a file that is genuinely in a legacy encoding such as Windows-1256, read as UTF-8. That needs the original bytes rather than pasted text, which is why it asks for the file.

A worked example

A colleague sends a CSV of customers and every Arabic name is a wall of Ø and Ù. Press Load a broken sample to see it.

The status line reads detected: mojibake and the repaired box shows the real names. أحمد ناصر was always أحمد ناصر — every byte was correct, and something along the way read them with the wrong table.

The French line in the sample shows the other common artefact: l’avance becomes l’avance. That ’ is a smart apostrophe, which lives in the Windows-1252 range and needs its own mapping — a repair that only handles Latin-1 leaves those behind.

Now test the safeguard. Paste correct Arabic — أحمد — and the tool reports that no mojibake pattern was found and leaves it alone. A repair applied blindly to good text turns it into garbage, and there is no undo once you have saved over the original.

Where this comes from, usually: Excel saving a CSV without a byte-order mark, an email client guessing wrong, or an older system defaulting to Windows-1256 for Arabic. Exporting to .xlsx instead of CSV avoids it entirely, because the format declares its own encoding rather than leaving the reader to guess.

Questions

How do I fix garbled characters like أحمد?

That is UTF-8 read as Windows-1252. The tool reverses the misreading and returns the original text, whether it is Arabic, French or an emoji.

What is mojibake?

Text written in one encoding and read as another. The bytes survive intact; only the interpretation is wrong, which is why it can be reversed.

Is my file uploaded?

No. The repair happens in your browser, which matters because the files affected are usually customer exports.

Why does é appear instead of é?

Because é in UTF-8 is two bytes, and reading them as Windows-1252 gives two separate characters: Ã and ©.

Why is Arabic full of Ø and Ù?

Same cause. Arabic letters are two bytes in UTF-8, and the first byte of most of them falls where Ø and Ù sit in Windows-1252.

Will it damage text that is already correct?

No. Text containing characters that could not have come from a single-byte decode is recognised as clean and returned untouched.

What if the repair does not work?

Try the second mode with the original file. If the file is genuinely in a legacy encoding rather than mis-decoded UTF-8, the bytes need re-reading rather than reversing.

What causes this in the first place?

Usually Excel saving CSV without a byte-order mark, an email client guessing the encoding, or an older system defaulting to a regional code page.

How do I stop it happening again?

Use .xlsx rather than CSV where you can — it declares its encoding internally. If it must be CSV, make sure the file starts with a UTF-8 byte-order mark.