Fix Garbled Text and Encoding on Windows

Garbled characters usually mean the file was read with the wrong code page. Learn to identify and fix the common Windows cases.

You open a text file and see a row of nonsense characters where accents, Chinese, or symbols should be. This is mojibake, and almost always it means the file was written in one encoding but read in another. Windows has a long history of code-page defaults that make this common.

This article explains the usual culprits, the byte-level facts behind them, and a reliable way to recover readable text without guessing. We also cover how to prevent the problem on files you create yourself.

The most common encoding mismatches

UTF-8 is the dominant encoding today, but Windows tools historically defaulted to a legacy code page. The classic mistake is a UTF-8 file opened as Windows-1252 (often called ANSI on English Windows). Each byte is then mapped to the wrong glyph, producing characters like é or  instead of é.

Another frequent case is CJK text. A file saved in GBK (a Chinese code page) read as UTF-8, or vice versa, produces gibberish across the whole document. The fix is to reopen the file with the correct code page, not to retype it.

A subtler case is UTF-16. Because it encodes each character as two bytes, a UTF-8 viewer shows every other byte as a space or a control character, making the text look like it has gaps. Recognizing the pattern avoids the wrong fix of deleting the 'spaces'.

Byte-level facts you can verify

Some facts are worth knowing because they let you confirm an encoding instead of guessing.

• UTF-8 BOM is the three bytes EF BB BF at the very start of a file. Its presence signals UTF-8 to many Windows programs.
• UTF-16 often begins with FF FE (little-endian) or FE FF (big-endian), and every ASCII character then appears as two bytes.
• CRLF vs LF: Windows line endings are the two bytes 0D 0A (carriage return, line feed); Unix uses a single 0A. Mixing them is harmless to readability but matters to some tools.
• GBK uses one or two bytes per character and overlaps visually with UTF-8 only by accident, so a wrong guess corrupts everything.

How to recover the text

The recovery step is to reopen the file with the encoding it was actually saved in, then save it as UTF-8 if you want a portable result. Most editors with an encoding menu let you switch decoding without altering the bytes until you re-save.

If the original encoding is unknown, start with the most likely candidate for the content: UTF-8 with BOM for modern Windows exports, GBK for Chinese text, Windows-1252 for legacy Western text. Reopening with the right one restores the characters instantly; the wrong one produces different garbage, which tells you to try the next candidate.

These are the common patterns; edge cases exist and depend on the exact bytes.

Preventing the problem

Set your editor to default to UTF-8 without BOM for new files, unless a specific tool requires a BOM. Keep a BOM only when the downstream consumer (some older Windows utilities) expects one. For CJK workflows, confirm GBK versus UTF-8 explicitly rather than relying on auto-detection, which cannot always tell them apart.

If you exchange files with others, state the encoding in the filename or a header comment. A file named data.utf8.csv removes all ambiguity and spares the next reader the recovery dance.

When a hex view helps

If encoding menus do not resolve it, open the file in a hex view and inspect the raw bytes. The byte pattern tells you the truth: a BOM, double-byte UTF-16 spacing, or high bytes that only make sense under GBK. Decoding from evidence beats trial and error, and it also reveals whether the file is actually binary rather than text.

Related: how to view large log files that may mix encodings, and how to open large files on Windows. Start from the FlyText overview.

Common questions

What is mojibake?

Mojibake is garbled text caused by decoding a file with the wrong character encoding, so each byte maps to the wrong glyph.

What are the bytes of a UTF-8 BOM?

A UTF-8 BOM is the three bytes EF BB BF at the start of the file.

Why do I see é instead of é?

Because a UTF-8 file was decoded as Windows-1252. Reopen it as UTF-8 to recover the text.

What is the difference between CRLF and LF?

CRLF is the two bytes 0D 0A used by Windows; LF is the single byte 0A used by Unix and macOS. The difference affects line endings, not character decoding.

How do I fix Chinese text showing as nonsense?

The file is likely GBK decoded as UTF-8 or vice versa. Reopen it with the correct code page, then save as UTF-8 if you want a portable file.

Keep reading