A PDF font can number its glyphs however it likes. A separate table maps those numbers to real characters. When that table is missing or wrong, the page draws correctly and copying returns nonsense.
Nothing can reconstruct the missing table from the file. Try a different reader, and if that fails, run OCR on the rendered page and use its output instead.
This is one of the stranger PDF failures, because every instinct says a document that displays correctly must contain correct text. It does contain text. The text just does not mean what it appears to mean.
Why display and copying disagree
Drawing a character and knowing what it is are two separate operations in a PDF, and they rely on different information.
To draw, the renderer takes a number from the content stream, looks up the glyph with that number in the embedded font, and paints the shape it finds. The number is just an index into a set of drawings. It never needs to know that the shape is the letter A.
To copy, something has to translate that number into an actual character. That translation lives in a separate mapping table inside the font. If the table is absent, the copy operation has a number and no way to interpret it, so it falls back on a guess, and the guess is usually wrong.
A number pointing at a shape in the embedded font. Meaning is irrelevant.
A table translating glyph indices into real characters.
The page renders perfectly, because rendering never consults that table.
Where the missing table comes from
Almost always font subsetting. To keep files small, PDF generators embed only the glyphs a document actually uses rather than an entire typeface. A document using forty distinct characters carries forty glyphs.
Renumbering is part of that process, and a correct generator writes an updated mapping table alongside it. Generators that skip that step, and there are many, produce files that display perfectly and cannot be copied from. The bug is in whatever created the PDF, and it is baked into the file from the moment it was written.
Recognising it
The characteristic signature is that the nonsense is consistent rather than random.
- Accented Latin charactersWrong map, right length
- Symbols and dingbatsGlyph indices read as a symbol font
- Correct spaces and line breaksStructure survives, characters do not
- Some words fine, others notMixed fonts on the page
- Numbers correct, letters wrongDigits often map by luck
Spacing surviving is the clearest tell. Word boundaries and line breaks come from positioning information rather than from the character map, so the shape of the text is intact while the characters are wrong. Genuine corruption does not usually preserve structure that neatly.
What actually helps
The information is not in the file, so no tool can recover it directly. Three approaches work around that, in increasing order of effort.
Try a different reader
Readers vary in how hard they try. Some compare the embedded glyph outlines against known fonts and reconstruct a plausible mapping. It costs a minute and occasionally solves the problem outright.
Try a text extraction tool rather than copy and paste
Some extraction libraries apply heuristics that interactive selection does not. Results vary by document, and it is worth one attempt before moving on.
Run OCR on the page
The reliable answer. Recognition ignores the broken text entirely and reads the rendered image, producing text from the shapes as displayed. It feels perverse on a born-digital document and it works.
Jumbled in a different sense
Sometimes the characters are correct and the order is wrong, which is a different problem with the same description.
Copying a two-column page can produce lines that alternate between columns, because extraction follows the order things were drawn in rather than the order they are read in. A generator that writes the page in an unusual sequence produces text that is individually correct and collectively scrambled. This is about reading order rather than encoding, and a reader with better structure analysis, or copying one column at a time, usually resolves it.
Read the page instead of the broken encoding
Recognition works from the rendered image, so a damaged character map stops mattering.
Common questions
Why it happens and what helps.
01Why does the text look right but paste as nonsense?
Because drawing a character and identifying it use different information. Rendering needs only a glyph index, while copying needs a mapping table that translates indices into real characters. When that table is missing, the page draws correctly and copying has nothing to work with.
02Is my PDF corrupted?
No. A corrupted file usually fails to open or renders incorrectly. This one displays perfectly, which shows the page content is intact. What is missing is a small table inside the embedded font.
03Can I fix the file itself?
Not straightforwardly. The mapping was never written, so there is nothing to repair and no way to derive it from what remains. Specialist tools can sometimes rebuild one by matching glyph shapes, with mixed results.
04Why do all PDFs from one source do this?
Because they share a generator, and the bug is in that software's font subsetting. It renumbers glyphs without writing an updated character map, so every file it produces has the same flaw.
05Does OCR really work on a document that is not a scan?
Yes, and it works well. The page renders sharp and straight, which makes it a better input than most real scans. Recognition ignores the broken text and reads the shapes as displayed.
06My text pastes with correct letters but scrambled order. Same problem?
No, that is reading order rather than encoding. Extraction followed the sequence the page was drawn in rather than the sequence it is read in, which happens on multi-column layouts. Copying one column at a time usually avoids it.