How to fix garbled characters in a text file on Mac
You can do this with Note My, and nothing is actually broken. The bytes on disk are the bytes the file has always had; here is how to decode them correctly and save the result out for good.
You open a file and the text is nearly there. Every accented letter has become two symbols, or a diamond with a question mark in it, or a blank. Sometimes every second character is missing. It looks like the file is corrupt, and it is tempting to start retyping.
Almost always the file is fine. A text file on disk is a sequence of bytes, and those bytes only turn into letters once they are read with a particular encoding. Read them with the wrong one and you get nonsense — reliably, repeatably, and reversibly. This guide covers how to tell which way it went wrong, how to re-read the file correctly in Note My, and how to save it out so it does not happen again.
Re-reading a file with a different encoding never writes to it. The file on disk is untouched until you deliberately save.
Why a file opens as nonsense
Two mistakes account for nearly all of it, and they look different on screen.
UTF-8 bytes read as a single-byte encoding. In UTF-8 an accented letter takes two bytes. Read those bytes one at a time as Windows-1252 and each letter becomes a pair of characters: café arrives as café, naïve as naïve, and a non-breaking space as  followed by a space. If your file is peppered with à and Â, this is what happened.
Single-byte or CJK bytes read as UTF-8. Going the other way, bytes that are not valid UTF-8 cannot be decoded at all, so they are replaced. You get question marks, replacement diamonds, or gaps where characters should be. Japanese or Chinese text read this way usually collapses into an unbroken run of junk rather than into neat pairs.
Our encoding handling opens files correctly the first time, so most days none of this comes up. What makes the occasional file interesting is the format itself: a plain text file carries no record of the encoding it was written in, so a short note, or a document that is almost entirely plain English, gives very little away about the machine it came from. That is where you take over. The encoding is yours to set, changing it takes one command, and all of it happens on your Mac: nothing is uploaded, there is no account, and the file never leaves the machine.
Read the encoding pill first
The status bar names the encoding the document is currently being read as. Look at it before you change anything. If it says Windows-1252 and the file came from a Mac or a Linux server, you already know which direction to move in.
Clicking the pill opens the same encodings the File menu carries: a Frequent section first, then one section per group. There are 18 encodings in total, in three groups.
| Group | Encodings |
|---|---|
| Unicode (10) | UTF-8 · UTF-8 with BOM · UTF-16 LE · UTF-16 BE · UTF-16 LE BOM · UTF-16 BE BOM · UTF-32 LE · UTF-32 BE · UTF-32 LE BOM · UTF-32 BE BOM |
| Legacy / Western (4) | Windows-1252 · ISO-8859-1 · Mac Roman · KOI8-R |
| CJK (4) | Shift JIS · EUC-JP · GB18030 · Big5 |
The Frequent list is the shortlist the menu puts in front of you inline: UTF-8, UTF-8 with BOM, UTF-16 LE BOM, UTF-16 BE BOM, Windows-1252, ISO-8859-1 and Mac Roman. Between them they cover most mis-read files. The rest sit under Other Encodings…
Re-read the file with the right encoding
-
Do this before you start editing
Reloading gives you back the saved copy of the file, so anything you have typed since your last save goes with it. Fix the reading first, then edit.
-
Choose Reload with Encoding…
It is at File ▸ Encoding ▸ Reload with Encoding…, and it opens a sheet. The command shows you the same file read a different way. It reads the file; it does not write to it.
-
Pick the encoding the file was written in
Not the one you would like it to be in — the one whoever created it used. The shortlists below narrow that down. A brief toast confirms the change, and the encoding pill in the status bar updates to match.
-
Read the result and repeat if needed
Accented words either read correctly or they do not, so you will know at once. If they do not, reload again with the next candidate. A wrong choice costs you nothing: the file on disk is left exactly as it is, and you can reload as many times as you need to.
Western European and Cyrillic files
If the text is broadly Latin with accents, work down this list. Windows-1252 first: it covers most text written on Windows, including curly quotes, dashes and the euro sign. ISO-8859-1 next — closely related, and the right answer for a lot of older Unix and web content. Mac Roman for files created on classic Mac systems, where an apostrophe or a bullet is the giveaway. KOI8-R when the file is Russian and Cyrillic letters are arriving as Latin gibberish.
Japanese and Chinese files
Four encodings cover this. Shift JIS and EUC-JP are the Japanese candidates — Shift JIS first for anything from a Windows or Japanese desktop application, EUC-JP for material from Unix systems and older mail archives. GB18030 is for Simplified Chinese, Big5 for Traditional Chinese. Once text is garbled you cannot tell them apart by eye, so try them in that order and stop when it reads.
Files where every second character has vanished
If the right letters appear but with a gap, a full stop or a blank between every one of them, the file is UTF-16 or UTF-32 being read as a single-byte encoding. Each character occupies two or four bytes, and the extra zero bytes are drawn as nothing.
Reload with UTF-16 LE BOM or UTF-16 BE BOM if the file starts with a byte-order mark, and the plain UTF-16 LE or UTF-16 BE variants if it does not. LE is much the more common on Windows. The same pattern applies to the four UTF-32 cases.
Reload and Convert are opposites
This is the distinction worth getting right. The two commands sit next to each other in the same menu and do the reverse of one another.
| Command | What it does | Use it when |
|---|---|---|
| Reload with Encoding… | Shows you the file again, read with the encoding you pick. Nothing is written to disk. | The file is being read wrongly and looks garbled. |
| Convert to Encoding… | Changes the encoding the text you have will be stored in the next time you save. | The file reads correctly and you want it stored differently. |
Converting a document that is already displaying garbage does not fix it. It writes the garbage out in a new encoding. Reload first, confirm the text reads correctly, then convert.
Save it out as UTF-8 so it stops happening
Once the document reads correctly, one more step ends it. Choose File ▸ Encoding ▸ Convert to Encoding…, pick UTF-8, and save with ⌘S. The file is then stored in the encoding every modern tool assumes, and the question stops coming up wherever the file goes next.
Two defaults are worth knowing. New documents are created as UTF-8, and preserve BOM is on — so a file that arrived with a byte-order mark keeps one unless you choose a variant without it. UTF-8 and UTF-8 with BOM are separate entries for exactly this reason.
Open anything and see what is really inside
Some of what lands in a downloads folder was never text to begin with. Note My tells you so before it opens one of those, a check that is on by default and that saves you working through encodings on an image or an archive. When you want to look inside anyway, File ▸ Open Anything as Text… (⇧⌘O) puts the contents on screen exactly as they sit on disk. It is the way into a file with no extension, one macOS has handed to another application, or a log with an unfamiliar suffix, and what you see is the file's own content, unedited and in the order it is stored — often enough to identify the file and read the strings buried in it.
What to do once the text reads correctly
Reloading is the fix. The four things below are what make it stick, and they are all worth doing while the file is still in front of you.
- Store it as UTF-8. Convert, then save. The file is now in the encoding every modern tool assumes, and the next application to open it has nothing to guess at. This is the single change that stops the question coming back.
- Sweep for look-alike letters. Homoglyphs, combining marks and non-NFC clusters are listed for you by our hidden-character scanner and then left exactly as they were. You see the full list and choose what happens to each entry; nothing is rewritten behind your back.
- Do a whole batch in one pass. Encoding belongs to the document you are looking at, so when several files all came from the same source, open them together and our macro recorder replays the same conversion across every open tab. One Undo takes the whole run back.
- Confirm with the bytes. Switch the invisible marker style to Bytes and read the hex straight off the page, so you commit to a conversion knowing precisely what the file holds rather than trusting the shapes on screen.
Underneath all of this sits one fact about the format: a plain text file carries no record of the encoding it was written in. The final say therefore sits with the person reading it, which is exactly where it belongs, and Note My gives you everything you need to exercise it. The pill in the status bar always tells you how the document is being read, one command re-reads it any other way, and you can do that as often as you like — the bytes on disk are untouched until you choose to save.
Troubleshooting
Only a handful of characters are wrong and the rest is perfect
That is not an encoding problem. A whole-file mis-read breaks every non-ASCII character, not three of them. More likely it is a look-alike letter or a stray invisible: a Cyrillic or Greek character that resembles a Latin one, a combining accent that did not compose, or a zero-width space. Open Clean ▸ Clean Invisible / Special Characters… and run our hidden-character scanner over the file. The findings table lists each one by Line:Col · Code Point · Category · Action · Risk, so you can jump straight to the line and see it in context. Cyrillic and Greek letters that masquerade as Latin ones are covered, and every finding is shown to you rather than quietly corrected, so you decide what happens to each one.
There is one odd character at the very start of the file
That is a byte-order mark. At the very start of a file it is legitimate, so you will not see it flagged there; the same character anywhere else in the document is reported as zero-width junk, which is where it actually causes trouble. If you want the file stored without one, convert to plain UTF-8 rather than UTF-8 with BOM.
I want to see the actual bytes rather than guess
Set the invisible-character marker style to Bytes in Settings ▸ Invisibles. It draws hex bytes in the document's own encoding, so a space is 20 in UTF-8 and 20 00 in UTF-16 LE, and a non-breaking space is C2 A0. It is the quickest way to confirm what the file really contains before you commit to a conversion.
It looked right on screen and came out wrong after saving
Almost certainly a reload where a convert was needed, or the reverse. Reloading changes only how the bytes are read. To change the file itself, convert and then save.
The file changed on disk while I had it open
You will be told, with a sheet offering Reload or Keep My Version. Reload brings in the copy from disk and replaces what is on screen. Keep My Version leaves your text as you have it, and the copy on disk stays as it is until you save over it.
Frequently asked questions
Does reloading with a different encoding change the file?
Your file stays exactly as it is. Reload with Encoding re-decodes the bytes that are already on disk, and nothing is written, so you can try as many candidates as you like. Only Convert to Encoding… followed by a save changes the file.
Which encoding should I try first for a Windows file?
Windows-1252. Most garbled Latin text started life on a Windows machine, so it is the candidate to try first. Check the pill in the status bar before you change anything, since it may already tell you where you stand. ISO-8859-1 is the next candidate, then Mac Roman.
Why do my accented letters appear as à and  pairs?
Because a two-byte UTF-8 character is being read as two separate single-byte characters. Reload the file as UTF-8 and the pairs collapse back into the letters they were.
Another program saved the garbled version over my file. What now?
Go back to a clean copy — an earlier version from your backups, a snapshot of the folder, or the original from whoever sent it. Once mojibake has been written into the bytes it becomes the file's real content, so the copy worth opening is the one that was never re-saved. Open that in Note My, reload it with the encoding it was written in, convert it to UTF-8 and save. The round trip that spoiled the first copy then has nothing left to catch.
Can I convert several open files at once?
Yes. Encoding conversion is one of the actions our macro recorder handles. Record the conversion once on a file you have already checked, then play it back with the scope set to All Open Tabs. One Undo takes the whole run back, so you can look at the result before saving.
Is the file analysed anywhere other than my Mac?
It all happens on your Mac. Note My contains no networking code of its own; the only network activity is performed by Apple’s own system services, to establish purchases and transactions state. There is no account, no telemetry and no upload. Your files stay on your Mac and never leave it, whatever encoding they are in.