If a Mac document shows garbled accents, replacement symbols, or text that looks like unrelated characters, first check whether it is a plain-text file being read with the wrong encoding. In TextEdit, reopen a copy using a different plain-text encoding and compare the affected passages. If the text still looks wrong, the cause may be a different file format, missing font, or damage; changing encoding is not a universal repair.

What an encoding problem looks like

A text file stores characters as bytes. An encoding maps between those bytes and readable characters. If an app interprets the bytes using a different encoding from the one used to save them, the result can be mojibake: recognizable text may turn into odd symbols or sequences of incorrect characters. The Unicode Consortium documents that Unicode text can be represented in formats such as UTF-8 and UTF-16, and that malformed UTF-8 data may produce an error or a replacement character. Unicode’s UTF-8, UTF-16, UTF-32 & BOM FAQ

Look for a pattern: ordinary English may remain intact while accented letters or non-Latin writing looks wrong, because those characters can use different byte sequences. A replacement diamond with a question mark or a row of � characters can indicate that the reader could not decode some data. These clues suggest a decoding issue; they do not identify the original encoding by themselves.

First identify what kind of file you have

TextEdit’s encoding choice applies to plain-text files. Before troubleshooting, note the file extension and how the document opens. Files such as .txt, .csv, or source-code files are often plain text, but an extension alone does not prove the file’s format. A Word document, PDF, or rich-text document has structure and formatting beyond plain text. Apple lists the formats TextEdit can open and distinguishes rich text from plain text. Apple’s TextEdit document guide

If the problem appears in only one app, try opening the same file in another suitable app, preferably without saving changes. If it looks correct there, the first app’s display or import behavior may be involved. If it is wrong in multiple apps, the file’s encoding or contents may be the issue. A different font can cause missing glyphs, but usually does not turn a whole passage into systematic garbled text.

Compare encodings in TextEdit without overwriting the file

  1. Make a duplicate of the file in Finder and use the duplicate for diagnosis. Keep the original unchanged while comparing options; saving after a mistaken interpretation can make recovery harder.
  2. Open TextEdit, choose File > Open, and select the duplicate without opening it yet.
  3. Click Show Options in the Open dialog. Under Plain Text Encoding, choose an encoding and click Open. Apple documents this per-file setting and says you can use Customize Encodings List if the option you need is not shown. Apple’s instructions for incorrectly displayed characters
  4. Compare the same short, known passage each time: names, accented words, punctuation, and the surrounding sentence. A plausible result should restore readable words consistently, not merely replace one strange character with another.
  5. If the source is known—for example, a file exported by a particular system—use its documented encoding as your next candidate. Without that information, try a small number of likely choices and treat any apparent improvement as a hypothesis until the text makes sense throughout.

Changing encodings for all files is available in TextEdit > Settings > Open and Save, under Plain Text File Encoding. Leave this default alone while diagnosing a single document: it changes how TextEdit opens other plain-text files too. Apple’s TextEdit settings guide

When changing encoding does not help

If every candidate produces unreadable or inconsistent text, stop cycling through options. The file may not be plain text, may be incomplete or damaged, or may contain text that was already corrupted before you received it. Ask the sender or source application which format and encoding were used, and request a fresh export if possible. A wrong encoding can make intact bytes look wrong; it cannot reconstruct characters that were lost or replaced earlier.

If the issue is limited to one symbol, compare its appearance in another app and check whether the chosen font includes that character. If the document is a PDF, Word file, or other formatted document, use an app suited to that format rather than converting it to plain text as a diagnostic shortcut. TextEdit’s Format > Make Plain Text removes formatting, so it is not a neutral way to inspect the original. Apple explains this conversion behavior.

Once a candidate encoding makes the copy readable, verify several parts of the document, then save a separate corrected copy only if you need a converted file. Reopen that copy to confirm it remains legible. Keep the untouched original until the corrected version has been checked in the app or workflow where it will be used.

Sources