Why did my text get corrupted?

Almost always mismatched encoding assumptions: one side writes UTF-8, the other reads Latin-1. The usual sources are the database connection character set, a missing or wrong Content-Type header, and files read without an explicit encoding.

Is the repair always possible?

If UTF-8 bytes were displayed through a single byte encoding, yes, because the bytes survived. If something in the chain replaced characters with question marks or the U+FFFD replacement character, the information is genuinely gone and cannot be recovered.

Will it damage my correct text?

Essentially never, and the reason is structural rather than a list of special cases: correct text almost never forms a valid UTF-8 sequence when its code points are reinterpreted as bytes, so the strict decoder throws and the run is left untouched. The exceptions are strings that genuinely are mojibake, such as "Ã‰cole" for "École". Paste something correct and watch the output stay identical.

Only part of my document is broken. What happens?

The tool locates the damaged runs individually and repairs each one, leaving the correct text between them untouched. It also reports how many runs it repaired, so you can compare that against what you expected.

There are still odd characters in the result. Why?

Two possibilities. The text may have been corrupted twice, which the tool handles on its own while reporting the pass count. Or the corruption is the ISO-8859-9 confusion, the "Ý" family, which needs the separate option enabled.

Mojibake Fixer - Mustafa Kürşad Başer

Key Takeaways

The common corruption is UTF-8 text read as Latin-1. "Türkiye" becomes "TÃ¼rkiye", and it is reversible because the bytes were never lost.
Real documents are usually only partly broken. A tool that decodes the whole string gives up on the first correct character and reports "no problem" for a document that visibly has one.
Not damaging correct text matters more than repairing broken text. A tool that rewrites a working document hands you the damage.
The "Ýstanbul" corruption is a different problem and is not detectable: Ý is a real letter in Icelandic and Czech. It is a separate, off by default option for that reason.

What actually happens to the text

UTF-8 is a variable width encoding. The letter ü is one character but occupies two bytes, C3 and BC. Read back through a single byte encoding such as Latin-1, those two bytes show as two separate characters: Ã and ¼.

text

1"Türkiye"  ->  as bytes: 54 C3 BC 72 6B 69 79 652read as Latin-1:  T  Ã  ¼  r  k  i  y  e   =  "TÃ¼rkiye"

Nothing was lost. The bytes are still there and are simply being shown with the wrong letters, which is exactly why the repair is possible: take each character back to a byte and read the sequence as UTF-8 again.

Why this tool will not touch correct text

The dangerous failure for a repair tool is not failing to fix broken text, it is breaking text that was already fine. In the first case the visitor finds no solution and moves on. In the second they lose a working document and may not notice for days.

The protection comes from strict UTF-8 decoding. Correctly written text does not form a valid UTF-8 sequence when its code points are reinterpreted as bytes, so the decoder throws and the run is left exactly as it was. The safety is a property of the operation rather than a checklist someone has to remember.

Note

Paste correct text into this tool and nothing changes. You can verify that directly: type "İstanbul" and watch the output stay identical.

Partly corrupted documents

A document is rarely broken from start to finish. In database exports the encoding changes at some point and correct rows sit beside corrupted ones. A page can have a clean title and a broken body.

A tool that decodes the whole string fails completely on that input: decoding throws at the first correct character and the answer comes back as "no corruption found". This tool finds the damaged RUNS instead and repairs each independently, leaving the correct text between them byte for byte identical.

text

1Input:   Türkiye ve TÃ¼rkiye2Output:  Türkiye ve Türkiye3         ^^^^^^^ untouched

Text corrupted twice

When corrupted text is saved again in its broken form, the mistake compounds. "TÃ¼rkiye" put through the same misreading becomes "TÃÂ¼rkiye", and a single repair pass is not enough: the first pass produces "TÃ¼rkiye", which is still wrong.

The tool repeats until the result stops changing and tells you how many passes it needed. Seeing two or more is useful information in itself: it means broken data was written back to the source, which usually points at a problem worth fixing upstream rather than in the document.

Why the Ý repair is separate

The second common Turkish corruption works differently. Confusing ISO-8859-9 with Windows-1254 or Latin-1 shows "İstanbul" as "Ýstanbul". Six letters are affected: İ, ı, Ş, ş, Ğ and ğ.

The mapping is unambiguous, but the DETECTION is not. Ý is a genuine letter in Icelandic and Czech, and so are Þ and Ð. Every byte sequence is valid in both encodings, so unlike the UTF-8 case there is no validity check to lean on. Nothing in the text proves it is Turkish.

Warning

Applying this automatically would corrupt any Icelandic or Czech text pasted in. It is off by default and appears only when your input actually contains letters it would change. When you enable it, check the result by eye.

Fixing the source

This tool rescues a document, it does not repair a system. If the corruption keeps coming back, the encoding assumption is wrong somewhere in the chain, and it is usually one of three places: the database connection character set, the Content-Type header on the HTTP response, or a file read without an explicit encoding.

On MySQL the first thing to check is utf8 versus utf8mb4. What MySQL calls "utf8" is not real UTF-8 and cannot store four byte characters, which is why emoji disappear. utf8mb4 is the correct choice every time.

Nothing leaves your browser

What you paste is never sent to a server. The repair runs entirely in your browser, and once the page has loaded you can disconnect and it keeps working. That matters here, because corrupted text is usually part of a database dump.

Frequently Asked Questions

Why did my text get corrupted?: Almost always mismatched encoding assumptions: one side writes UTF-8, the other reads Latin-1. The usual sources are the database connection character set, a missing or wrong Content-Type header, and files read without an explicit encoding.
Is the repair always possible?: If UTF-8 bytes were displayed through a single byte encoding, yes, because the bytes survived. If something in the chain replaced characters with question marks or the U+FFFD replacement character, the information is genuinely gone and cannot be recovered.
Will it damage my correct text?: Essentially never, and the reason is structural rather than a list of special cases: correct text almost never forms a valid UTF-8 sequence when its code points are reinterpreted as bytes, so the strict decoder throws and the run is left untouched. The exceptions are strings that genuinely are mojibake, such as "Ã‰cole" for "École". Paste something correct and watch the output stay identical.
Only part of my document is broken. What happens?: The tool locates the damaged runs individually and repairs each one, leaving the correct text between them untouched. It also reports how many runs it repaired, so you can compare that against what you expected.
There are still odd characters in the result. Why?: Two possibilities. The text may have been corrupted twice, which the tool handles on its own while reporting the pass count. Or the corruption is the ISO-8859-9 confusion, the "Ý" family, which needs the separate option enabled.

Tool and article by Mustafa Kürşad Başer, Senior Software Engineer. Published: August 2026.