Extract Text from a PDF
The text, reflowed into reading order — and, above it, the part other extractors leave out: which pages actually gave you text, which ones are scans, and which ones have a text layer that decodes to nothing readable.
🔒 Your document never leaves your browser.
Drop a PDF here
One PDF at a time · nothing is uploaded
An empty page and an unread page look identical
A scanned page has no text layer. Ask any extractor for its text and you get back an empty string — the same answer a genuinely blank page gives. That is the failure mode worth designing against: the output is not wrong, it is silent, and whatever reads it next concludes the page had nothing on it. Here those pages are named, counted, and pointed at the OCR tool.
Text that is not text
A second, quieter failure: a font embedded with a custom encoding and no ToUnicode map. The glyphs draw correctly, so the page looks perfect, while the characters behind them are private-use codepoints that mean nothing. Copy that text anywhere and you get rubbish. This page flags it instead of handing it over as if it were prose.
What this deliberately does not do
No table reconstruction and no layout analysis. Getting a table out of a PDF with its rows and columns intact is a different problem with dedicated tools, and pretending otherwise would just produce plausible-looking nonsense. What you get here is the text, in reading order, with an honest account of which pages it came from.
Every check this tool runs (4 rules)
PDX-001 This page has no text layer
The page carries no extractable text at all, which almost always means it is a scan — an image of a page rather than a page. Extraction returns an empty string, and the danger is that an empty string reads as "this page is blank" rather than "this page has not been read". Run OCR over those pages first.
Fix: Add a text layer with the OCR tool, then extract again.
yaktool engineering rule, not a citation from a specification: derived from how PDF text extraction behaves in practice. A page with no text layer, a font without a ToUnicode map, and a truncated result are three ways an extraction can look successful and be useless.
PDX-002 The text layer extracts as gibberish
Text came out, but a large share of it is replacement characters or private-use codepoints. That happens when a font is embedded with a custom encoding and no ToUnicode map: the glyphs draw correctly on screen while the characters behind them mean nothing. It is worse than an empty page, because the output looks like text and will be read as text.
Fix: OCR the page instead of trusting its text layer — the rendered glyphs are correct even though the encoding is not.
yaktool engineering rule, not a citation from a specification: derived from how PDF text extraction behaves in practice. A page with no text layer, a font without a ToUnicode map, and a truncated result are three ways an extraction can look successful and be useless.
PDX-003 Output was cut to fit the character budget
The requested budget was reached before the whole document was emitted. The number of characters dropped and the pages that produced no output at all are both reported, because a silently shortened extraction is indistinguishable from a short document.
Fix: Raise the budget, or ask for a page range.
yaktool engineering rule, not a citation from a specification: derived from how PDF text extraction behaves in practice. A page with no text layer, a font without a ToUnicode map, and a truncated result are three ways an extraction can look successful and be useless.
PDX-004 A requested page is not in the document
A page number outside the document was asked for. It is reported rather than ignored so that a range typed one off does not look like a page that happens to be empty.
yaktool engineering rule, not a citation from a specification: derived from how PDF text extraction behaves in practice. A page with no text layer, a font without a ToUnicode map, and a truncated result are three ways an extraction can look successful and be useless.