Mojibake Repair — Fix Garbled Text

Repair garbled text by testing every plausible encoding pair in your browser.

local

mojibake-fixer

🖥 Every candidate is decoded in your browser. Nothing is sent anywhere.

Paste the garbled text

§01 ABOUT THIS TOOL

Overview

Mojibake is not damage. It is correct bytes read with the wrong table. 日本語 encoded as UTF-8 is nine bytes; read as Windows-1252 those same nine bytes are æ—¥æœ¬èªž. Nothing was lost — the interpretation was wrong, and reversing it restores the original exactly.

This tool re-encodes the text you paste back to bytes using the encoding it was probably misread as, then decodes those bytes with each encoding it might really have been, and ranks the results. The top candidate is the pair that produces valid UTF-8 with no replacement characters.

How to use

Paste the garbled text.
Read the top candidate, marked with a star.
If it is not right, check the others — each is labelled with the pair that produced it.

Why the top candidate is usually right

The ranking is not a guess about language. It relies on a structural property of UTF-8: the encoding declares its own sequence lengths. A lead byte states how many continuation bytes follow, and every continuation byte is identifiable as one. An arbitrary byte sequence therefore fails to decode as UTF-8 almost immediately, and the browser’s decoder reports that failure as replacement characters.

So when one candidate decodes as UTF-8 with no replacement characters, that is strong evidence rather than a preference — the bytes were valid UTF-8 all along, which is exactly what you would expect from text that was UTF-8 before something read it as Latin-1. Candidates are further ranked by whether the result still contains mojibake signatures, and a candidate is only offered if it reduces them.

Why correct text is left alone

Before producing any candidate, the input is checked for the signatures of mojibake: the specific byte pairs Latin-1 misreads produce (Ã, Â, â€, ã and their relatives), C1 control characters in the U+0080–U+009F range, and U+FFFD replacement characters.

Text with none of these is reported as clean and no candidates are offered. This matters because the transformation is destructive when applied to correct text. Grüße and señor are ordinary German and Spanish; run them through a repair that assumes they are garbled and you get nonsense. A tool that always offers candidates invites exactly that mistake.

What cannot be recovered

If the text contains ?, ? or empty boxes, the original bytes are gone.

The distinction is worth being precise about. Mojibake preserves the bytes and loses the interpretation, so it is reversible. Substitution loses the bytes: when a converter meets a character its target encoding cannot represent, it writes a replacement and discards the original. No tool recovers that, because there is nothing left to reinterpret. If you can still get the source file, that is the only path.

Double mojibake — garbled, saved, then garbled again — is sometimes recoverable by applying the repair twice, but each pass compounds any loss, so results degrade.

Where mojibake comes from

The pattern is nearly always a default that was never declared:

CSV opened in a spreadsheet. Excel on Windows historically assumed the system code page for .csv unless a UTF-8 BOM was present, which is why exported files full of accents open as garbage.
A database connection whose charset was not set. The data is stored correctly and the connection converts it wrongly, so the same rows are readable through one client and garbled through another.
Email subject lines. Headers are ASCII-only, so non-ASCII travels as RFC 2047 encoded-words that name their own charset. Japanese subjects still commonly use ISO-2022-JP, and a decoder that assumes UTF-8 garbles every one.
A response with no charset in its Content-Type. The browser guesses, and its guess depends on locale.
A legacy filename in an archive. ZIP has no reliable charset field, so filenames created under one code page are read under another.

Examples

Repairing an imported CSV — paste one affected field to identify the pair, then re-import with the correct encoding rather than repairing rows one at a time.
Reading a garbled email subject — for a full message, .eml viewer decodes encoded-words using the charset the header declares, including ISO-2022-JP, so the subject reads correctly without any repair.
Diagnosing a pipeline — the pair that produces the fix tells you where the conversion is wrong. “Written as UTF-8, read as Windows-1252” is a missing charset declaration at the reading end, not a problem with the data.
Checking log output — a service logging in one encoding and an aggregator reading in another produces mojibake only for non-ASCII lines, which is why it goes unnoticed until a name or an error message from a translated system appears.

Notes

Candidates are decoded with the browser’s own TextDecoder, so the tables are the ones the platform uses — no encoding table is shipped with this page. Support for the legacy multi-byte encodings is required by the Encoding Standard and is present in all current browsers.

Encodings covered are windows-1252, iso-8859-1, windows-1251 and macintosh on the misread side, and utf-8, shift_jis, euc-jp, iso-2022-jp, gbk, big5 and euc-kr on the original side. Up to eight candidates are shown.

Always read the candidate before using it. On a short sample several pairs can produce plausible output, and the structural check cannot tell you which language the text was meant to be in. Everything happens in your browser — see the privacy policy.

FAQ

Is my text sent anywhere?

No. Each candidate is produced with the browser's own TextEncoder and TextDecoder. Nothing leaves the page, and after it loads it works offline — which matters because garbled text usually comes from a real document, a customer record or a log.

Why are several candidates shown instead of one answer?

Because more than one encoding pair can produce readable text, and only you know which language the text should be in. The candidates are ranked, and the top one is the pair that decodes as valid UTF-8 with no replacement characters — a structural property, not a guess about the language.

It says the text is not garbled, but it looks wrong to me.

The check looks for the signatures of mojibake: the byte pairs Latin-1 misreads produce, C1 control characters, and U+FFFD replacement characters. Text with none of these is very unlikely to be repairable by re-decoding, and offering candidates anyway would just corrupt correct text. Grüße and señor are correct, not garbled.

It says it looks garbled but no candidate is cleaner. What now?

Usually the text was garbled twice — encoded wrongly, saved, then encoded wrongly again — or it went through an encoding outside the pairs covered here. A longer sample helps, because more bytes make the correct pair easier to distinguish. Text that already contains replacement characters cannot be recovered at all; that information is gone.

Why can question marks and boxes never be recovered?

Because the original bytes were discarded. When a converter cannot represent a character it substitutes U+FFFD (?) or a placeholder, and the substitution is not reversible. Mojibake is recoverable precisely because the bytes survived and only the interpretation was wrong.

Which encodings are covered?

Misread as windows-1252, iso-8859-1, windows-1251 or macintosh; actually written in utf-8, shift_jis, euc-jp, iso-2022-jp, gbk, big5 or euc-kr. That covers the great majority of mojibake in practice, because the misreading side is nearly always a single-byte Western default.