Why you cannot copy text out of a PDF, and what to do instead

The one-second test

Open the PDF, click at the start of a paragraph and drag across a single line, then paste what you selected into a plain text editor rather than into a word processor.

• The text highlights and pastes as text. There is a usable text layer, so nothing is missing — skip to the section on garbled copy below, where the interesting failure lives.
• Nothing highlights, or one blue rectangle covers the whole page. There is no text at all. Every page is a picture of a page, and no amount of selecting will ever produce a character from it.
• It highlights but pastes as boxes, question marks or nonsense. The text is present and the mapping is broken. This is the case people misdiagnose as "no text", and it has a different cause and a different fix.

This test also predicts what a compressor will do. A PDF with no text layer can be rendered and re-encoded freely, which is exactly the operation that shrinks scans so well. A PDF with a text layer cannot be treated that way without destroying the thing that made it worth having.

Four ways a PDF ends up without usable text

• It was scanned or photographed. The most common cause by a wide margin. A scanner produces one image per sheet, and the software wraps those images in a PDF. The result is a container for pictures, and nothing inside it knows that the pictures contain words.
• The text was converted to outlines. Design and prepress workflows often replace live text with its drawn shape so the file no longer depends on a font being installed. The letters look identical because they are the same letterforms — they are simply curves now, and curves have no characters. This is the one case where the text was sacrificed on purpose.
• A compressor rasterised the pages. Many browser-based and low-cost compressors cannot re-encode the images inside a PDF object by object, so they render each page to an image and rebuild the document from those. It works beautifully on scans and destroys text documents, and it is the usual reason a file that used to be searchable is not any more.
• The font is embedded but carries no character mapping. The text is genuinely there as text; the file simply never records which glyph means which character. Usually the result of subsetting a font for size and writing the subset without its Unicode mapping table.

Garbled copy is a different failure from no copy

If dragging over a line produces a selection but pasting gives rows of empty boxes, question marks, or text that appears to be a different language entirely, you are looking at a mapping problem rather than a missing layer.

Here is what is happening. A PDF does not store characters in the ordinary sense. It stores glyph indices and positions, and relies on a table inside the font to say which index corresponds to which character. Embedding only the glyphs actually used is the correct, space-saving thing to do — but if the producing application writes that subset without the reverse mapping, the file still draws perfectly and simply cannot tell you what it drew.

The diagnostic takes seconds: paste the selection into a plain editor and look at exactly what came out. A word processor may silently substitute something plausible and hide the problem from you.

This is also the honest explanation for why PDF-to-Word conversion is hard, and why the tools on this site do not offer it. Rebuilding an editable document means reconstructing paragraphs, columns, tables and reading order from positioned glyphs — and the files where that matters most are frequently the files where the mapping is already broken.

What OCR is, and why it is not a browser job

Optical character recognition is the only way to create a text layer that was never there. It looks at the image of each page, works out which shapes are probably letters, and writes a text layer on top. The page image stays; the text sits over it invisibly so it can be selected and searched.

It is not something a browser tab can do well. A capable OCR engine carries language data and glyph models measured in tens of megabytes, needs pages deskewed and binarised before it starts, and still makes mistakes on poor input. A model small enough to run comfortably in a phone browser would produce text that is worse than useless: plausible enough to search, wrong often enough to mislead.

What you can do is make the input good enough that a proper OCR tool succeeds. These are the changes that actually move the result:

• Scan at 300 dpi. Below roughly 200 dpi small type starts merging; above 400 dpi you gain almost nothing but file size.
• Scan text in greyscale or bitonal rather than colour, unless colour carries meaning. The engine cares about contrast, not hue.
• Straighten the sheet. Two or three degrees of skew is enough to break line detection.
• Scan flat rather than from a bound book where you can. Curvature near the spine is the hardest thing for an engine to handle.
• Do not over-compress before OCR. Heavy JPEG compression leaves grey fringing along strokes that the engine reads as extra characters.

If you have already pushed a poor scan through a compressor and now need the text, start again from the original scan. Re-scan if you still have the paper; if you do not, treat the compressed copy as a picture of the document rather than as its text.

What to try, by cause

Keeping the text layer when you squeeze a file

• Compress a copy, never the only copy. If the result loses its text, you have lost nothing but a little time.
• Test the output the same way you tested the input — drag over a line and paste it somewhere plain. It takes two seconds and catches the failure before you send the file.
• If the document is text-heavy, reduce size by removing pages, cropping margins or downsampling images, not by re-rendering pages.
• When exporting from a word processor, use a preset that keeps text and embeds fonts, rather than printing through an image-based driver.
• When exporting from design software for print, keep a second copy with live text even if the version you send has its fonts outlined.

Where each tool on this site leaves the text layer

This is worth stating tool by tool, because "PDF tools" covers a range of operations and only some of them can damage the text at all.

If the text layer matters, the safe operations are the ones that only move or clip pages. The risky ones are the ones that rebuild the page from pixels, and the deliberate one is outlining.