You copy a paragraph from a PDF and paste symbols, shifted letters or empty boxes, even though the page reads perfectly. The page is fine. The map that tells software which letter each glyph stands for is missing or broken. Here's how to recognize each kind of mess and get clean text out.
Because a PDF doesn't store words. It stores instructions to draw glyphs, the shapes in a font, at positions on a page. When you copy, the viewer has to work backwards from "glyph number 37 in this font" to "the letter T". If the file tells it how, the copy is perfect. If it doesn't, the viewer guesses, and a wrong guess gives you symbols, shifted letters or empty boxes while the page itself looks fine.
The piece that does the translating is called a ToUnicode map. Programs that create PDFs are supposed to include one for every font, and most modern ones do. Problems usually come from older software, some print-to-PDF drivers, files with fonts subset under a custom encoding, and now and then a publisher that scrambles the map deliberately to discourage copying.
The kind of mess tells you the cause, and the cause tells you the fix:
| What you see when you paste | Likely cause | Fix |
|---|---|---|
| Random symbols or letters shifted by a few places ("Uifsf" for "There") | Font has a custom encoding and no ToUnicode map | OCR the page |
| Boxes, question marks or blank spaces | Glyphs map to nothing, or your app lacks the font for the characters | OCR, or paste into an app with a wider font |
| "fi", "fl" missing or pasted as one odd character ("efficient", "oce") | Ligatures, two or three letters drawn as one glyph | Find and replace, or a better extractor |
| Right words, wrong order; columns interleaved | Text is stored in drawing order, not reading order | Extract by page region, or copy one column at a time |
| Nothing copies at all | Scanned image with no text layer, or copying disabled | OCR; or check document properties for restrictions |
| Hyphenated words split and line breaks everywhere | Every visual line is a line in the file | Rejoin lines in a text editor |
The first row is the classic. The font's internal numbering doesn't match standard letter codes, so every character comes out as a different but consistent one. That consistency is a tell: if every "e" turns into the same symbol, it's an encoding problem, not a damaged file, and repairing the PDF won't change it.
Less common than its reputation, in our test. We ran pdffonts and pdftotext (Poppler) over 41 unique PDFs from our own working files and counted the damaged words:
| Result | Detail |
|---|---|
| 41 unique PDFs tested | Reports, slide decks, specs, brochures, a government white paper |
| 35 of 41 | Every font had a ToUnicode map; all extracted cleanly |
| 6 of 41 | At least one font had no ToUnicode map |
| 3 of those 6 | Extracted with no damaged words at all |
| 2 of those 6 | A handful of words with stray control characters (2 of 22,700 words; 5 of 18,276) |
| 1 of those 6 | 94-page white paper: 344 of 357 font entries had no map. Body text fine; all 37 contents-page lines came out as long runs of � symbols where the dot leaders were |
| 2 of 41 | No text at all (image-only pages); only OCR helps |
The lesson is that a missing ToUnicode map isn't fatal on its own. Good extractors fall back on the font's built-in encoding and glyph names, and for standard fonts those are usually enough. Gibberish appears when the fallback has nothing meaningful to work with, which in our sample happened to decorative characters rather than words. A different extractor can do better or worse on the same file, though, so if one tool gives you garbage, try another before reaching for OCR.
Yes. Some publishers subset fonts with scrambled codes so that the page reads fine but copied text doesn't. It's a crude form of copy protection and it also breaks screen readers, search and accessibility checks. A file can also set a permission flag that tells viewers not to allow copying; that's different, because the text is intact and the viewer simply refuses. Either way, the text you see on screen is still there to read, and OCR or a careful retype gets it out. If you need a picture of the page rather than its text, PDF to JPG does that directly.
If the problem is a blank page rather than garbled text, that's a different set of causes; see why is my PDF blank. For pulling clean text from normal files, how to extract text from a PDF covers columns, page ranges and tables.
The font in the PDF has no ToUnicode map, or a broken one, so the viewer can't tell which letter each glyph stands for. It guesses, and the guess comes out as symbols or shifted letters even though the page looks fine. OCR fixes it by reading the page as an image.
Rarely. Real corruption usually stops pages from opening or leaves them blank. If every instance of a letter turns into the same wrong character, the file isn't damaged, the font encoding is, and repairing the PDF won't help.
Plain copy and paste only carries text, not layout. For a handful of lines, copy one column at a time. For tables, extract page by page and rebuild the table, or ask for the original source file.
Only when the text layer is missing or broken. When the PDF has a good text layer, copying is exact and OCR can only add errors. Use OCR when the paste is gibberish, empty, or the PDF is a scan.
Many fonts draw fi, fl, ff and ffi as single combined glyphs called ligatures. If the PDF doesn't map those glyphs back to the separate letters, they paste as one unusual character or nothing at all. Find and replace fixes it.