Why PDF Text Extraction Returns Garbled or Empty Text
Extraction problems look like bugs in the converter. Almost always they are accurate readings of what the PDF actually contains — which is why knowing the cause tells you the fix.
PDF internals · · 4 min read
A PDF does not contain text the way you think
The mental model most people carry is that a PDF is a document with text in it, wrapped in formatting. It is not. A PDF is a sequence of drawing instructions: place glyph number 47 from this embedded font at these coordinates, at this size. Repeat a few thousand times per page.
There is generally no stored concept of a paragraph, a column, a table, or a reading order. Frequently there is not even a stored concept of a word — the spaces you see may be positioning offsets rather than space characters. Everything above the level of "a glyph at a coordinate" is something a human eye infers from the rendered result.
Extraction is therefore reconstruction, not reading. A tool takes positioned glyphs and infers lines, words and order. When it gets that inference wrong, it is usually because the document is genuinely ambiguous — not because the tool is broken.
Empty output: the file is a scan
By far the most common complaint, and the easiest to diagnose. If extraction returns nothing at all, the PDF almost certainly has no text layer. Scanners, phone camera apps and fax-to-PDF systems all produce the same thing: one large image per page. The characters are pixels. There are no glyphs to extract.
Confirm it in five seconds: open the PDF in any viewer and drag your cursor across a line of text. If nothing highlights, it is an image.
The fix is OCR, which infers characters from their shapes. Run the file through an OCR step first, then extract. Some scanned PDFs already carry an invisible OCR layer behind the image — those extract fine, at whatever accuracy the original OCR achieved.
Scrambled order: multi-column layouts
Academic papers, newsletters and reports in two or three columns often extract as interleaved nonsense — the first line of column one, then the first line of column two, then back again.
The cause is that reading order comes from the order the glyphs were drawn in, or from their coordinates, and neither reliably encodes "finish this column before starting the next". A generator that emits content row by row across the full page width produces exactly this interleaving. The extractor is reporting the file honestly.
Options: extract page by page and reassemble manually for a short document; use JSON output and sort lines by horizontal position to separate columns programmatically; or convert the pages to images with PDF to JPG and use a vision model, which reads layout the way an eye does.
Missing or extra spaces
Text that arrives as "thequickbrown" or, less often, "t h e q u i c k", comes from the same root cause. Many PDF generators do not emit space characters at all; they simply position the next glyph slightly further along. The extractor has to decide, from the gap width, whether a space belongs there.
Justified text makes this harder, because inter-word spacing is stretched to align both margins — so the gap that means "space" varies line by line. Tightly kerned or condensed fonts push in the other direction and can produce spurious spaces inside words.
There is no clean fix at the extraction stage; the information was never written. For bulk processing, a spell-corrector or a small language model pass repairs the majority of cases cheaply.
Ligatures, hyphens and odd characters
Sequences like "fi", "fl" and "ffi" are frequently drawn as a single ligature glyph. If the font maps that glyph back to its component characters, extraction is clean; if it does not, you get a replacement character or a missing letter in the middle of otherwise perfect words — "of ce" instead of "office".
Hyphenated line breaks are a different matter. A word split across two lines keeps its hyphen in the extracted text, because the hyphen genuinely is in the file. Rejoining those is a post-processing step, and one that has to be careful not to destroy legitimately hyphenated compounds.
Smart quotes, en and em dashes, and non-breaking spaces all extract as their actual Unicode characters, which surprises pipelines expecting ASCII. That is correct behaviour, not corruption.
Tables
Tables are the hardest case, because in a PDF a table is not a table. The ruling lines are vector graphics; the numbers are independently positioned text. Nothing in the file states that a particular number belongs to a particular column.
Extracted as prose, a table becomes a run of values in whatever order the glyphs were drawn — usually readable by a human who already knows the shape, and near-useless to a program. If tabular data matters, extract with position information via JSON and reconstruct columns by clustering horizontal coordinates, or use a vision model on page images.
Checking before you commit to a pipeline
Before building anything on top of a corpus, extract a handful of representative documents and read the output. Look for empty pages, interleaving, missing spaces and mangled tables. Five minutes of this predicts more downstream trouble than any amount of pipeline design.
Every tool on this site runs in your browser, so testing a confidential document against them involves no upload and no disclosure. Start with PDF to Text for a raw look, then PDF to Markdown to see whether structure survives.