Why PDFs lose their text structure
A PDF does not store words, sentences or paragraphs. It stores instructions to draw glyphs at coordinates. When you extract text you are reconstructing structure that was thrown away at export: the extractor collects positioned glyphs and infers, from their coordinates, where words and lines probably were.
This is why spacing is often imperfect. If a document was typeset with kerning applied as individual positioning operations, adjacent letters may each be drawn separately, and the extractor must decide whether a small horizontal gap is letter spacing or a word break. Get that threshold slightly wrong and you get "th e re sult" or "theresult".
Reading order is a harder problem still. Glyphs appear in the content stream in whatever order the generator emitted them, which need not be the order a human reads. Multi-column layouts, sidebars, footnotes and tables all interleave, so text from two columns can come out alternating line by line. Well-made PDFs include a tagged structure tree describing the true reading order — the same information screen readers rely on — but most PDFs in the wild are untagged.
Encodings, ligatures and the ToUnicode map
Each font in a PDF maps character codes to glyphs, and that mapping is arbitrary — a subsetted font might use code 1 for "e". To recover actual characters, the extractor needs the font's ToUnicode CMap, an optional table mapping glyph codes back to Unicode. When a generator omits it, extraction produces plausible-looking gibberish, because the codes are being read as though they were text.
Ligatures cause a subtler version of the same problem. Typographic ligatures such as fi and ffl are single glyphs, and if the ToUnicode map is missing or lazy, "file" can extract as "le" with the ligature silently dropped. Scanning a large extraction for words that lost their opening letters is a quick way to spot it.
Other recurring artefacts: soft hyphens from justified text leaving hyphens mid-word, non-breaking spaces that look like spaces but are a different character, and typographic quotation marks where you expected straight ones. Normalising all of those is usually the first step after extraction — the text tools handle the common cases.
When there is no text at all
A scanned document contains no text objects whatsoever. Each page is a single image, and extraction correctly returns nothing, which people frequently mistake for a broken tool. The test is simple: try to select text in a PDF reader. If nothing highlights, there is no text to extract.
Recovering it requires optical character recognition, which is a different operation — analysing pixels to recognise characters — and it introduces its own error rate, typically higher on low-resolution scans, unusual fonts, or pages photographed at an angle. The image-to-text tool handles that case.
Some PDFs are hybrids, where OCR has already been run and an invisible text layer sits behind the scanned image. Those extract fine, but the text you get is the OCR engine's output including its mistakes, not a transcription anyone verified.