BASALT · JOURNAL
Why text copied from a PDF comes out as gibberish
Text copied from a PDF comes out as gibberish when the file draws the right shapes but doesn't say which letters they are. A PDF stores numbered glyphs, and copying works only if the file also carries a way to translate those numbers into characters. When that translation is missing or wrong, you paste symbols, boxes, the wrong letters or nothing.
The same missing table is why search fails. Search tools read the same translated text, so a page that pastes as nonsense usually can't be searched either. If a word you can see on the page isn't found, suspect this before you suspect your spelling.
What a PDF actually stores
A PDF page doesn't contain the sentence you read. It contains drawing instructions: use this font, then draw the glyphs with these codes. A code is just a number in the font's own scheme. Code 87 might be a W in one font and a ligature or a blank in another.
For text to come back out, an extractor needs a way to turn each code into a Unicode character. There are two ways. One is a standard encoding the font names, such as WinAnsiEncoding or MacRomanEncoding, which tells every reader what each code means. The other is a /ToUnicode table attached to the font, which maps codes to characters explicitly. Without either, the extractor guesses or gives up.
The page itself looks fine either way, because drawing a glyph only needs the shape from the font file. Appearance and meaning are stored separately. That's the whole reason a PDF can look perfect and still copy as garbage.
What goes wrong in the file
A few situations produce the mismatch, and they all end in missing or wrong translation.
- Fonts with custom encodings and no table. Software that subsets a font for a document can assign its own codes to the glyphs it keeps. If it forgets to write the
/ToUnicodemap, the codes mean nothing outside that font. - Fonts built from drawn shapes. Type 3 fonts define each glyph as a little drawing, and a reader has no automatic way to know that a drawing is an "e" unless the file says so.
- Ligatures and decorative glyphs. A single glyph for "fi" or "ffl" can come back as one odd character, or as a character that a search for "fi" may not match.
- Text converted to outlines. The letters are filled shapes, like a logo. There are no characters at all to copy.
None of these shows on the page. Why you can't select text in a PDF covers the related cases where selection fails outright, such as scans. Here, selection works and the result is wrong.
How to check on your Mac
Start with the simplest test. Select a line in Preview, copy it, and paste it into TextEdit. If the paste shows symbols, wrong letters, or nothing, the file's translation is the problem. Then use Preview's Find on a word you can see, and note whether it's found.
For a second opinion that doesn't depend on Preview, ask Spotlight's importer what text it can extract. This test-imports the file and stores nothing in the index:
mdimport -t -d3 document.pdfLook for the kMDItemTextContent line. On macOS 15, a sample page that draws "Hello world" in Helvetica, with a /ToUnicode table that maps every code one character off, gave kMDItemTextContent = "Ifmmp!xpsme". PDFKit, the PDF framework in macOS, extracted the same string and found no match for "Hello". A page whose codes pointed at made-up glyph names gave back no text at all.
Then look at the fonts themselves. Install qpdf with brew install qpdf, make an uncompressed copy, and list the font entries:
qpdf --qdf --object-streams=disable document.pdf expanded.pdf
grep -a -E '^ *(/BaseFont|/Encoding|/ToUnicode|/Subtype */(Type3|Type0|CIDFontType2|TrueType|Type1))' expanded.pdfEach font shows a /BaseFont name, and a subset has a six-letter prefix and a plus sign, like AAAAAB+Monaco. Read what comes with it. A line /Encoding /MacRomanEncoding or /WinAnsiEncoding means standard codes, and a /ToUnicode line means an explicit map. The usual suspects are a /Type0 font with /Encoding /Identity-H and no /ToUnicode, whose codes are bare glyph numbers, and an /Encoding dictionary whose /Differences give glyphs made-up names.
The list explains a result. It doesn't predict one. A map, when present, overrides the standard encoding, so the "Hello world" page above declared /WinAnsiEncoding and still copied as nonsense. The reverse also happens: a subset TrueType font in a file printed to PDF on macOS 15 had no /ToUnicode at all, declared /MacRomanEncoding, and extracted perfectly. Judge by what the paste and mdimport give you.
What fixes it
You can't repair the translation table from the outside, so the fixes are about getting text another way.
The best fix is a better copy. Ask whoever made the file to export it again, or export it yourself from the source document. The setting names vary by app, so look for an option that embeds fonts or keeps the PDF searchable, rather than one that converts text to outlines. A fresh export with different settings may include the map the first one lacked.
If you only have the file, OCR is the fallback. OCR reads the pixels of the page the way a person would, recognizes the letters, and adds a text layer you can search and copy. It's a reading of the picture, so check numbers and names against the page. OCR on a Mac walks through it, and a scanned PDF that won't search covers the case where there was never any text. For fonts that merely look wrong on another machine, see when PDF fonts look wrong.
One related risk for redaction. If you're hiding text on such a page and the tool can't map the characters it's removing, you can't be sure what you've removed. Redacted text that still shows is worth reading before you share the result.
Frequently asked questions
Why is copy and paste from a PDF gibberish?
Because the PDF stores glyph codes for drawing, and the file lacks a reliable table translating those codes into letters. The page looks right while the pasted text is symbols or the wrong characters. Check it in Preview by pasting a line into TextEdit.
Why does copying text from a PDF to Word give gibberish?
Word receives whatever text the PDF yields when you copy, and the problem is in the PDF, not Word. If the paste into TextEdit is already wrong, Word will be wrong too. Get a better export of the file, or run OCR on the page and copy from the result.
Why can't I search in my PDF?
Search uses the same text extraction as copying. If the file's fonts have no usable mapping, the words you see on the page don't exist as searchable text, and Find returns nothing. A scanned page has the same symptom for a different reason: it's only a picture.
Why is search not finding words in my PDF that I can see?
Three common reasons: the text maps to the wrong characters, a ligature glyph stands in for letters you typed, or the page is an image. Paste a line into TextEdit to see which. If it pastes correctly but still doesn't match, try a shorter word that avoids "fi" and "fl".
Does a missing ToUnicode always cause gibberish?
No. If the font uses a standard encoding, extraction works without it. On macOS 15, a TrueType subset with MacRomanEncoding and no /ToUnicode extracted correctly. The risk is a custom encoding, or bare glyph numbers, with no map, and a map that's simply wrong breaks extraction even when the encoding is standard.
Can I fix the gibberish without the original file?
Not by repairing the map. You can OCR the page to create a new text layer, which is a reading of how it looks. Check anything that matters afterward, such as numbers, against the page itself.
Is gibberish text a sign of a damaged PDF?
Usually not. Damaged files tend to fail to open or show missing pages. Gibberish when copying means the file displays correctly but lacks the text mapping, which is a property of how it was made.
Doing it in Basalt
Basalt can add the missing text layer. Make Searchable runs on-device OCR with Apple's Vision and places an invisible text layer over the words it read, with progress and a cancel button. By default it skips pages that already have text, so if a page with broken text is skipped, turn that option off. The old text then stays in the file too, next to the new layer. Redaction has a related safeguard: if a mark touches text whose characters Basalt can't map reliably, it refuses instead of guessing, and tells you to rasterize the page at 300 DPI and mark it again. Every tool writes a new file and leaves your original untouched. It's $29 once for up to three Macs, free for 24 hours.
Redaction that proves itself
Basalt destroys the content you mark, then re-opens the file it wrote and proves the content is gone before it saves anything. Your documents never leave your Mac.
