Garbled Characters in a Text File: How to Diagnose and Fix Encoding Problems

Quick answer

Garbled characters in a text file almost always mean the bytes are being decoded with the wrong character encoding. The file itself usually isn't damaged. Two symptoms cover most cases: a wall of accented-looking junk where readable text should be, or the exact sequence  sitting at the very top of the file. Below: how to tell the two apart, repair the file with a standard command-line tool, and stop it from happening again.

How it actually works

Why plain English text can look fine with the wrong encoding

UTF-8 is backward-compatible with 7-bit ASCII — the first 128 Unicode code points encode identically in both. So a file of plain English text looks correct no matter which encoding a tool thinks it's using, right up until an accented letter, a curly quote, or a non-Latin character shows up. Only then does the mismatch become visible, which is why "garbled text" bugs often surface long after the file was actually saved with the wrong tag (Wikipedia: UTF-8).

The three root causes of mojibake

The garbled-text phenomenon has a name — mojibake — and it comes from one of three places. An underspecified encoding: no charset was declared, so the reading application falls back to a locale default that may not match. A mis-specified encoding: the file was explicitly labeled wrong, the classic example being an email client that tagged Windows-1252 content as ISO-8859-1. Or protocol layering: an HTTP header, an HTML meta tag, and a byte order mark disagreeing about what encoding is actually in play (Wikipedia: Mojibake).

Double encoding — the compounding case

The worst version of this bug happens when correct UTF-8 bytes get misread as a single-byte encoding like Windows-1252, then re-saved as "UTF-8" on top of that misreading. Each round-trip compounds the damage. A single accented character can turn into a longer and longer string of garbage the more times a file gets opened and re-saved by tools that don't agree on the encoding (Wikipedia: Mojibake).

Step-by-step: diagnosing and fixing the file

Spot the symptom

Before reaching for a fix, narrow down what's actually wrong:

• `` at the very top of the file — a UTF-8 byte order mark (the three bytes EF BB BF) being displayed as Windows-1252. This is a distinct, single-cause bug, separate from general mojibake (Wikipedia: Byte order mark).
• Scattered garbage throughout the body — a genuine encoding mismatch on the whole file.
• Wrong-looking quotes or dashes only — often a different bug entirely. If it's isolated to quotation marks inside code samples, check smart quotes sneaking into code snippets before assuming it's a full encoding problem.

Confirm it's UTF-8 (or isn't)

UTF-8's byte structure makes it unusually easy to verify automatically. Lead bytes carry a prefix that signals how many continuation bytes follow, and continuation bytes always start with 10. In a random byte stream, a byte with the high bit set has only a 1-in-15 chance of accidentally forming a valid UTF-8 sequence — so if a file passes a UTF-8 validity check, it's almost certainly actually UTF-8, no metadata required (Wikipedia: UTF-8). Most editors and IDEs expose this as an encoding indicator in the status bar. If it says something other than UTF-8, that's your starting point.

Repair it with iconv

On macOS and Linux, iconv is the standard command-line tool for converting between encodings:

iconv -f iso-8859-1 -t utf-8 infile.txt -o outfile.txt

-f is the source encoding — swap in whatever the file turns out to actually be; Windows-1252 and ISO-8859-1 are the most common culprits. -t is the target, and -o writes the result to a new file instead of overwriting in place. Still looks wrong afterward? The file may be double-encoded. Run the same conversion a second time, then check one known accented character to confirm the fix actually held before trusting the whole file.

Common problems and fixes

Files that "fix themselves" then break again

Some editors silently re-encode a file on save, using whatever their own default happens to be. If a file keeps reverting to garbled after each edit, check the editor's default save encoding and set it to UTF-8 explicitly rather than relying on auto-detection.

Line-ending noise that looks like an encoding bug but isn't

A file with mismatched line endings between Windows and Unix tools can look like an encoding issue in a diff or a terminal, even though the character encoding itself is fine. If a "garbled" file is really just full of stray carriage returns, that's a CRLF vs. LF problem, not a mojibake one — worth ruling out before reaching for iconv.

Accented file names breaking across systems

A related but separate bug shows up in file names rather than file contents — a filename with an accented character can look fine on one machine and broken on another because of how Unicode represents that character. That's a normalization issue, covered in why accented file names break between Mac and everything else.

Doing this with Carets

Carets keeps every file as plain text, saved as UTF-8 by default — no proprietary format sitting between what you type and what's on disk, and nothing silently re-encoding a file behind your back. That matters because most mojibake starts the moment a file passes through a tool that assumes the wrong charset; a plain-text-first editor removes that hop entirely. Your files stay portable and future-proof, and the same notes and code open correctly whether you're on iPhone, iPad, or Mac. The Unicode Consortium itself recommends UTF-8 as "the preferred form for Unicode text files" (Unicode FAQ) — writing in an editor that treats that as the default, not an afterthought, is the simplest way to avoid debugging this again.

Carets is free to download on the App Store for iPhone, iPad, and Mac.

Frequently Asked Questions

What causes garbled characters (mojibake) in a text file?

Mojibake happens when a file's bytes are decoded with the wrong character encoding — the file isn't corrupted, it's being misread. The three usual causes are: no encoding was declared and the app guessed wrong from locale settings; the file was mislabeled with an incorrect encoding; or a tool re-saved already-correct text through the wrong encoding a second time (double encoding).

Why does my file show  at the very start?

That three-character sequence is a UTF-8 byte order mark (BOM) being misread as Windows-1252. The BOM (EF BB BF in UTF-8) is meant to flag the file as Unicode, but many parsers, shells, and JSON readers don't expect those extra bytes at the top of the file and render or choke on them.

How do I fix a file that's already garbled?

On the command line, iconv converts between encodings directly: iconv -f iso-8859-1 -t utf-8 infile.txt -o outfile.txt, swapping the -f value for whatever the file's actual source encoding turns out to be. If the text still looks wrong afterward, it may be double-encoded — run the same conversion a second time and check a known accented character to confirm the fix held.

How can I stop this from happening again?

Save and re-save everything as UTF-8 without a BOM, and make sure your editor, terminal, and any Git configuration all agree on that encoding. UTF-8 is the Unicode Consortium's own recommended default for text files, it's backward-compatible with ASCII, and its byte structure makes it one of the few encodings that's reliably auto-detectable — which is why standardizing on it prevents most mojibake before it starts.

Conclusion

Garbled text is a decoding mismatch, not file damage, and in nearly every case it's fixable in one or two passes of a standard conversion tool. The longer-term fix is boring on purpose: pick UTF-8, declare it explicitly everywhere a file passes through, and remove the guesswork that caused the problem in the first place.