You drag across a paragraph and nothing highlights. Or a blue box swallows the whole page at once. Or the text highlights properly, you paste it, and out comes ƒ‡ˆ‡ ››•›. Three different failures, three different causes, and the fix for one does nothing for the others.
Two documents that look the same
A PDF page can be built two ways, and on screen they are indistinguishable.
A typed PDF — one exported from Word, from a browser, from a design tool — stores instructions. Put glyph number 68 from this font at this position, then glyph 82, then glyph 82 again. The page is a set of drawing commands, and the letters are in there as data.
A scanned PDF stores a photograph. Someone put paper on a glass plate and the result is a single image, usually a JPEG, stretched to fill the page. There is no text in the file. There is a picture of text, which is a different thing entirely, and the difference is invisible until you try to select something.
How to tell in five seconds
Try to select a single word. If nothing highlights, or the entire page highlights as one block, it is a scan. If individual words highlight, there is real text.
The second test is the file size. A page of typed text is usually 10–60 KB. A scanned page at a normal resolution is 300 KB to 2 MB, because it is a photograph. A twenty-page document at 30 MB was scanned; the same document typed would be under a megabyte.
The third is to zoom to 400%. Typed text stays sharp at any zoom, because it is drawn from a font at whatever size you ask for. A scan turns into visible pixels, and often you can see the grey speckle of the paper around the letters.
When the text is there and still comes out wrong
This is the frustrating one, because selection works — the words highlight one by one, so there is clearly text in the file — and the paste is garbage anyway.
The reason is that the numbers stored in the page are not letters. They are positions in a font: glyph 68 is whatever the font's table says is 68th, and in a subset font, embedded to save space, that ordering is arbitrary. The producer of the file may have renumbered the glyphs so the ones actually used come first.
To make that reversible, a PDF is supposed to carry a ToUnicode map — a small table saying glyph 68 means the letter D. It is optional. Plenty of tools omit it, particularly older LaTeX pipelines, some CAD exporters, and anything that embeds a font by subsetting it without writing the map back out.
Without that table, the viewer draws the page perfectly, because drawing only needs the glyph shapes. Copying needs the map, and there is no way to reconstruct it from the file. The text is present, correct, and permanently unreadable to a machine.
There is a milder version of the same fault: the map exists but is wrong for ligatures. Copy a document set in a serif font and fi and fl vanish or turn into odd characters, because those pairs are drawn as a single glyph and nobody mapped it back to two letters.
What to do with each
Real text, correct map. Nothing is wrong; extract it. An extractor pulls the strings out in reading order, which is faster and more reliable than selecting across page breaks by hand — and it gets you the whole document rather than the part you managed to drag over.
Real text, missing map. Extraction returns the same garbage the clipboard did, because it is reading the same numbers. The only route is to treat the page as a picture and read it back optically, which is the same answer as for a scan.
A scan. There is nothing to extract, so the text has to be recognised from the image. That is OCR.
What OCR actually costs
Optical character recognition looks at the shapes and guesses letters. On a clean 300 dpi scan of a printed page in a language it has a model for, it is very good — accurate enough that the errors are rare and obvious.
It degrades quickly outside that. A photograph taken at an angle, a fax, a page with a coffee ring on it, or handwriting will produce output you have to read against the original anyway. Tables lose their structure, because the recogniser sees rows of characters and not a grid. Two columns often interleave into nonsense unless the layout is detected first.
It is also the one job on this site that genuinely needs a download: an English recognition model is around a megabyte, and other languages more. That is a real cost imposed once, not a reason to send the document to a server — the recognition itself runs perfectly well in a browser once the model is there.
The one that is not a technical problem
A PDF can carry a permissions flag that says copying is not allowed. Viewers that honour it grey out the copy command. The text is present, the map is fine, and the file is politely asking the software not to let you have it.
It is worth knowing what that flag is and is not. It is not encryption of the content — in the common case the page data is not encrypted at all, and every extractor that does not implement the check reads it straight out. Whether you should is a question about the document and not about the format, and the format is not going to help you decide.
The short version
Select one word. If it highlights, the text is real — extract it rather than dragging. If the paste is garbage, the file is missing its ToUnicode map and no extractor will do better; recognise it as an image instead. If nothing highlights, it is a photograph of a page and always was.
All three tests take longer to describe than to run, and running them first saves the twenty minutes people usually spend retyping a document that would have copied cleanly.