Why does opening text with the wrong encoding produce garbled characters?

A text file contains bytes; an application has to interpret those bytes as characters. Character encoding defines that mapping. If the application uses an incompatible encoding, the resulting characters can be incorrect, producing garbled-looking text often called mojibake. [S1]

So the key question is whether the text was interpreted incorrectly, or whether the correct characters are present but cannot be displayed properly. A different app or setting may help you compare those possibilities, but the garbled appearance alone does not establish the cause. If you still have the original file, keep an unchanged copy while investigating.

Look at the underlying characters, not only their appearance. If they are themselves the wrong characters—rather than the intended letters or symbols—a decoding mismatch is a plausible cause. Compare the same bytes using the known intended encoding; if that produces the expected characters, it supports that explanation. [S1]

If the underlying characters are correct but some appear as empty boxes, substitutes, or otherwise unsuitable visual forms, investigate font coverage or rendering. A glyph is a visual representation of a character, and fonts contain different sets of glyphs. [S1] [S2] These clues help narrow the search; they do not guarantee a diagnosis for every application or file.

Start by recording what you observe and where: note the file or text, the application, whether the problem affects all text or only some characters, and what you expected to see. Then compare the same content in another viewer or with another available encoding option, changing one thing at a time. The useful comparison is the same bytes interpreted under the known intended encoding—not just a different-looking display. [S1]

If you do not know the intended encoding, avoid treating a guess as a confirmed fix. Check whether the text’s creator or the application that produced it can identify the encoding, if that information is available. If you cannot establish it, record that uncertainty and preserve the original so later comparisons remain possible.

Here is a hypothetical example. Suppose a file is expected to show “café,” but one application displays different, unintended characters. That visible change is consistent with an encoding mismatch, but the example alone does not prove which encoding was intended. Compare the underlying text from the same bytes using the known intended encoding. If instead “café” is the underlying text and only the accent appears as a box or substitute, check whether the font or rendering can show the needed glyph. [S1] [S2]

You can copy and fill in this note:

“Expected text: [what I should see]. Observed text: [what appears]. File or source: [name or description]. Application: [name]. Scope: [all text / selected characters / other]. Comparison tried: [same content and what changed]. Intended encoding: [known value / unknown]. Underlying characters appear: [correct / incorrect / unsure]. Next question: [what information or comparison is still needed].”

Keep observations separate from conclusions: write “possible encoding mismatch” rather than labeling it confirmed unless the comparison supports that conclusion.