Why text copied out of a PDF comes out as gibberish

You can read the page perfectly and the clipboard gives you nonsense. That is not a bug in your reader — it is a gap in the file, and it is worth knowing which gap.

By Morn Tithsinara · Updated 21 August 2026

A PDF stores glyph numbers, not characters

When a PDF draws text, it does not say "draw the letter A". It says "draw glyph 36 from this font". A glyph number is an index into the font file, and it means nothing outside that font — glyph 36 might be A in one typeface and a comma in another.

That is fine for display, because the font is right there. It is a problem for copying, which needs actual characters. So the format carries an optional side table called ToUnicode: a map from glyph numbers to the Unicode characters they represent. When your reader copies text, it is reading that map.

Everything that goes wrong with copied text is a defect in that map, or its absence. And because the map plays no part in displaying the page, a document can render immaculately with a map that is wrong, partial or missing entirely — and nothing warns anyone, because nobody looked.

The failure modes, from mild to total

Ligatures. Typographic fonts draw "fi" and "fl" as single glyphs. If those glyphs are not mapped back to two characters, copying "efficient" gives you "ecient" — a word with letters missing, which is easy to skim past and disastrous in a quoted figure. Search the copied text for the word you know is there; if it is not found, this is usually why.

Missing spaces. A PDF does not have to store spaces. It can simply position the next word further along, and many typesetting systems do exactly that for justified text. Extractors infer a space when the gap is wide enough, and on tight justification they infer wrong. This is why copied prose sometimes arrives asrunwordstogether.

Wrong characters throughout. If the map is absent, an extractor falls back on guessing — commonly by treating the glyph number as if it were a character code. Occasionally that is right. Usually it produces a page of confident, structured, complete nonsense.

Subsetted fonts. This is the nastiest case. To keep files small, PDF writers embed only the glyphs actually used and renumber them from scratch. If the writer then emits a ToUnicode map covering only some of them, you get a document where half the characters copy correctly and half come out as garbage — which reads as corruption rather than as a mapping problem, and is much harder to diagnose than a page that fails completely.

Why non-Latin scripts suffer most

Complex scripts make every one of the problems above worse, because the relationship between characters and glyphs is not one to one to begin with.

In Arabic, a letter has different forms depending on its neighbours. In Devanagari and Khmer, consonants and vowel signs combine into conjunct clusters drawn as single glyphs. Correct extraction requires the map to record that one glyph stands for a sequence of characters — and writers get this wrong constantly, because the page looks right either way.

There is a second table that helps: ActualText, which lets a document state outright what a stretch of drawing operations really says, independently of the glyphs. Where a writer emits it, it is authoritative and worth more than any amount of glyph-level guessing. Where it is absent and the font is subsetted, a script like Khmer can come back so unreliably that the honest answer is to say so rather than hand over a plausible-looking wrong string. That is why a text box opened over Khmer in Edit PDF text always opens empty rather than pre-filled: text read back out of a subsetted Khmer font is too often wrong to present as if it were the document's.

Diagnosing it in under a minute

Copy a paragraph you can read and paste it into a plain text editor. Three outcomes, three different problems.

You get the right words. The map is fine. If a tool downstream is still producing rubbish, the problem is in that tool, not the file.

You get nothing at all. There is no text layer — the page is an image. This is a scan, or a PDF exported as pictures. Run OCR PDF, which writes a genuine text layer over the images and sidesteps the mapping question completely.

You get structured nonsense — the right number of "words", the right line breaks, wrong characters. That is a broken or missing map. The page is text, but the file will not tell you what the text says.

What to do about a broken map

A missing or wrong ToUnicode table cannot be repaired from outside the file — the information is genuinely not there, and inventing it would mean guessing what the document says. Two practical routes exist.

The first is to bypass the text layer entirely: render the pages and recognise them. OCR PDF reads the pixels, so a broken glyph map is irrelevant to it. On a document whose text is unextractable but perfectly legible, this works well, and it is the standard remedy.

The second applies when only some of the text is affected — extract what is good with PDF to Markdown, which reads the PDF's own text layer and joins each page into a continuous block, then check the character count under the download. It is a fast way to see how much of a long document actually extracts before you commit to converting all of it.

It is also worth checking whether the problem is upstream. If you produced the PDF yourself, exporting again from the source with a different writer, or with font subsetting turned off, will frequently produce a file that copies cleanly. That is a far better fix than any amount of downstream repair.

Questions