Everyone who has copied a paragraph out of a PDF has seen some version of the same failure: line breaks in the middle of sentences, stray hyphens, or worse, a string of characters that bear no resemblance to the words on the page. These are not random glitches. Each one traces back to a specific, well-understood decision in how the PDF format represents text, made decades ago for reasons that had nothing to do with how the file would eventually be copy-pasted.
A PDF doesn't store text the way you think
A PDF page is a sequence of drawing operators: move to this coordinate, select this font, draw this string of glyph codes, move to the next coordinate, repeat. There is no paragraph object, no sentence object, no concept of reading order beyond whatever order the drawing operators happen to appear in the file. When you select text with your cursor, the PDF viewer is not selecting "a sentence." It is selecting a span of glyph-drawing operators that happen to fall within your selection rectangle, and handing you back whatever string those operators encode.
This is why selecting text across a column boundary, or across a table cell, often produces text in the wrong order: your visual selection has no relationship to the order the underlying operators were written in, and copy-paste follows the latter, not the former.
Font subsetting and the ToUnicode CMap
Here is the part that produces genuinely garbled output, not just misordered output. A PDF does not have to encode text using standard character codes at all. To keep file size down, most PDF-generating software embeds a subsetted font, one containing only the specific glyphs actually used in the document, and assigns those glyphs arbitrary internal codes that have nothing to do with Unicode or ASCII. Glyph code 41 might be the letter "e" in one PDF and a completely different character in another, because the mapping is private to that specific embedded font.
To let you copy readable text despite this, a well-formed PDF includes a separate lookup table called a ToUnicode CMap, which translates each font's private glyph codes back to real Unicode characters specifically for copy-paste and text extraction. When a document generator omits this table, gets it wrong, or was produced by software that never populated it correctly (common with PDFs converted from older desktop publishing formats), extraction has no reliable way to recover the actual characters. This is the specific, root cause of the "random symbols instead of text" failure mode: it is not corruption, it is a missing or broken translation table for a font that was never meant to be read as anything but pixels.
Why ligatures and kerning compound the problem
Typography adds a second layer of distortion on top of encoding. A ligature, the fused single glyph used for character pairs like "fi" or "fl" in high-quality typesetting, is frequently stored as one glyph with one code point mapped to both letters at once, or sometimes to neither correctly. Extraction that doesn't handle ligature decomposition can turn "difficult" into "di culty," silently dropping the fused pair. Kerning and justified spacing, meanwhile, are stored as positioning adjustments between glyphs rather than as space characters, which is why naive extraction sometimes inserts extra spaces where none exist, or none where a space clearly should be. Neither of these is an error in the PDF. Both are correct instructions for how to draw the page, and both actively work against the goal of recovering clean, linear text.
What "clean" extraction actually requires
Reliable extraction has to do three things a simple copy-paste cannot: read glyph positions and group them into visual lines by coordinate rather than file order, so column and table layouts extract in the right sequence; rely on (or reconstruct) a working glyph-to-Unicode mapping rather than trusting a potentially broken embedded one; and apply a second pass of cleanup, rejoining hyphens and merging wrapped lines, to undo the specific artifacts that font subsetting and page-based layout leave behind. This is a fundamentally different process from selecting text with a cursor, which is why the results are so different in practice.
The text cleaner handles the coordinate-based line reconstruction and the hyphen and line-break cleanup pass; it relies on PDF.js for the underlying glyph-to-Unicode decoding, which handles the well-formed majority of PDFs correctly. The field guide goes further into how each of these corrections is applied, for anyone who wants the full mechanics rather than just the summary.