Skip to content
TextArray1.41.0
100% local

Charset detector

Guess the original encoding behind garbled text and recover it.

Input
Output
Related tools
BOM manager (add / remove)Text cleaning
Normalize Unicode textStylish text
Hash identifierDeveloper tools
Baudot code translatorEncoding & conversion
Timezone converterEncoding & conversion
Intel HEX parserEncoding & conversion
Charset detector
Paste text where accented letters have turned into strings like "PrĂ­liš" or "GrĂ¶ĂŸe" and this tool guesses what went wrong. The usual cause is a UTF-8 file opened, saved or piped through something that assumed a single-byte code page — Windows-1250 or ISO-8859-2 for Central European text, Windows-1252 for Western European text. Each accented character was originally two or three UTF-8 bytes; read one byte at a time under the wrong code page, they become exactly this kind of double garbage.
The detector works by trying the reversal for each candidate code page and checking whether the result is well-formed UTF-8 — a structural test that correctly encoded text essentially never passes by accident, which is why auto-detect can apply a fix with real confidence rather than a coin flip. When it finds a match it shows the guessed original encoding, the guessed misread encoding, and the recovered text, plus how many characters the fix removed (mojibake is always longer than the text it came from, since each broken character used to be several).
Auto-detect only guesses the verifiable direction — UTF-8 shown through the wrong code page. The rarer reverse case, a Windows-1250 or ISO-8859-2 file read as Latin-1, has no equivalent structural check, so it is offered as a manual option in the dropdown for when you already suspect that is what happened, rather than guessed silently. This is a heuristic tool, not a guarantee: text mixing several languages or containing symbols outside the target code page's range may not be recoverable, and it says so plainly instead of returning a confident wrong answer.
Everything runs locally in your browser using the same encoding tables browsers use to render web pages — nothing you paste is uploaded anywhere, which matters here more than most tools, since garbled text often comes from real customer records, exported databases or support tickets.
FAQ
How does it know which encoding was used?
It re-encodes the garbled text under each candidate code page and checks whether the resulting bytes form valid UTF-8. Correctly encoded text essentially never passes that check by chance, so a match is a reliable sign of what happened — not a certainty, but close.
Why does auto-detect not offer to fix "read as Latin-1"?
That direction has no equivalent way to verify itself — many byte values are valid letters in more than one code page, so it can produce plausible-looking but wrong text. Pick it manually from the dropdown when you already know that is the situation.
Can it fix text with emoji or mixed languages?
Only if every character in the text belongs to the candidate code page. A single emoji or a character outside that range means the whole line cannot be reversed, and the tool leaves it unchanged rather than guessing.
Is this guaranteed to be correct?
No — it is a heuristic, not a certified converter. It is very reliable at recognising genuine UTF-8-as-legacy-codepage mojibake and will say plainly when it cannot find a safe fix, rather than returning a confident wrong answer.
Is my text uploaded anywhere?
No. Detection and recovery both run entirely in your browser using the same encoding tables it already ships for rendering web pages — the text never leaves your device.