Your Scanned PDF Has No Text. Here's Why AI Can't Summarize It — and the Fix.

What "scanned PDF" actually means, technically

A PDF file can hold two very different kinds of content that look identical when you open them. A "native" or "digital" PDF — one exported from Word, Google Docs, LaTeX, or most modern software — stores actual characters: every letter, space, and line break is encoded data that a computer can read, select, search, and copy. A "scanned" or "image-only" PDF is different: it's a container holding a photograph (or a series of photographs) of a printed page. To a human eye reading it on screen, both look like a page of text. To a computer trying to extract that text programmatically, the scanned version is just pixels — no more readable as text than a photo of a street sign is readable as a text file.

This distinction is invisible in casual use and becomes very visible the moment any tool tries to extract, search, or summarize the text. It's also why "just use a smarter AI model" doesn't fix it — summarization models read text, and there's no text there to read. The fix has to happen one layer earlier, at the image-to-text conversion step, which is what OCR (optical character recognition) does.

How @vustSummaryBot's PDF pipeline actually handles this

To be precise rather than hand-wavy about it: @vustSummaryBot's PDF extraction (packages/summary-telegram/src/pdf-extractor.ts) parses the PDF file looking for an existing text layer. If it finds one — the normal case for reports, papers, contracts, and most documents produced digitally — it extracts the text and the usual summary pipeline runs: bullet points, paragraph, key takeaways, or TL;DR, exactly as described on the main /summary/pdf page. If it finds no text layer, the extractor returns a specific error code (no_text) with the message "PDF contains no extractable text (scanned/image-only)" — an honest failure, not a hallucinated summary or a guess based on the filename.

The web tool at /summary/pdf works the same way, using client-side text extraction in your browser (so the file itself never leaves your device) — but it's the identical text-layer-only approach, with the identical scanned-PDF limitation. Neither surface runs an OCR pass on a PDF. This isn't an oversight waiting to be patched — OCR on multi-page scanned documents is a meaningfully different, heavier processing step than text extraction, and building it into every PDF upload would slow down the 95%+ of PDFs that already have a text layer for the sake of the minority that don't. The honest design is to fail clearly and fast on a scan, and point you to the one-step fix, which is what this page does.

Four symptoms that tell you a PDF is scanned

You don't need special software to check — any PDF viewer shows these signs within seconds.

1. You can't select text with your cursor. Try to click-and-drag to highlight a sentence, the way you'd select text in an email. On a native PDF, the sentence highlights and you can copy it. On a scanned PDF, either nothing highlights at all, or the entire page selects as a single rectangular block (because the "text" is actually one embedded image).

2. Ctrl+F / Cmd+F finds nothing. Search for a word you can clearly read on the page. If the search comes back empty even though the word is visibly right there, the PDF viewer's search function — which only searches actual encoded text — has confirmed there's no text layer.

3. Zooming in shows paper texture, not clean vector text. Native PDF text stays crisp at any zoom level because it's rendered from font data, not pixels. A scanned page gets visibly grainy, shows JPEG-style compression artifacts, or reveals the physical texture of the original paper when you zoom past 200%.

4. The page has a slight rotation, skew, or uneven lighting. A perfectly straight, evenly-lit page can still be a scan, but a page with a barely visible tilt, a darker edge where the scanner bed's lid didn't press flat, or a slight curve near the spine (common with book scans) is a strong tell — these are physical scanning artifacts that only appear on photographed pages, never on digitally generated PDFs.

If a document fails even one of these checks — especially the copy-paste test — treat it as a scan and run OCR before trying to summarize it.

The OCR-first workflow, step by step

1. Confirm it's actually scanned. Run the copy-paste test above on a couple of pages. Mixed documents exist too — a digitally-typed report with one scanned signature page, for instance — in which case only the scanned pages need OCR; the rest already has a usable text layer.

2. Run OCR on the scanned pages. Several options work, at different levels of convenience:

   • macOS Preview or Adobe Acrobat can OCR a scanned PDF and save a new, text-searchable version — a good option if you're already on a Mac or have Acrobat.
   • Google Drive + Google Docs will OCR a PDF automatically if you upload it to Drive and open it with "Open with Google Docs" — free, and works from any browser.
   • Tesseract (open-source, command-line) handles batches well if you're comfortable with a terminal and have many scanned pages to process at once.
   • @vustMarkdownBot's photo path handles this differently: it doesn't OCR a PDF file, but it does OCR a photo. If your scan is only a page or two, export each page as an image (a screenshot of the PDF page works) and send each one to @vustMarkdownBot as a Telegram photo — it runs DSLab OCR on the image and returns the extracted text as Markdown. This is a real, working shortcut for short documents; for a 40-page scanned report, a dedicated OCR tool that processes the whole PDF at once is faster.

3. Verify the OCR output before summarizing. OCR isn't perfect — it can misread similar-looking characters (0/O, 1/l/I), mangle unusual fonts, or garble tables and multi-column layouts. A quick skim of the extracted text, especially numbers and names, catches the errors that matter before they propagate into a summary that treats a misread number as fact.

4. Paste the extracted text into @vustSummaryBot or /summary/pdf. Once you have real, selectable text — whether from a downloaded OCR'd PDF, a Google Docs export, or a Markdown file from @vustMarkdownBot's photo path — it goes through the exact same summarization pipeline as any other document: paste it as text, or save it as a .txt/.pdf and use the normal upload flow. There's no special "OCR mode" needed on the SummaryBot side; from its perspective, OCR'd text and originally-digital text are indistinguishable.

Why this two-step process is actually the right design, not a missing feature

It's tempting to want "just handle it automatically" — upload the scan, get the summary, no manual OCR step. But bundling OCR into every PDF summarization request would mean every user pays the processing cost (both in time and, on a hosted OCR service, in actual compute cost) for a problem that affects a minority of PDFs. Splitting the concerns — text extraction handles the common case fast and free, OCR is a deliberate extra step you take only when you actually have a scan — keeps the common path fast while still leaving a real, documented route for the scanned case. The alternative, silently attempting OCR on every PDF "just in case," would also make failures harder to diagnose: a bad OCR read on a document that actually had a clean text layer is a worse outcome than clearly extracting the text that was already there.

The honest failure message — "no extractable text (scanned/image-only)" — is deliberately specific rather than a generic error, precisely so you know immediately that the fix is OCR, not a retry, not a different file format, and not a different summarization tool. Any AI summarizer built on text extraction (which is most of them) will hit the identical wall on the identical file; this isn't a SummaryBot-specific gap you'd solve by switching products.

What summarizes well once you've done the OCR step

Once OCR'd, scanned documents summarize exactly as well as native ones — the summarization model can't tell the difference, and doesn't need to. Old academic papers only available as library scans, historical documents, printed forms, and photographed textbook pages all work fine post-OCR. The main quality variable at that point isn't "was this scanned" but "how clean was the OCR pass" — a crisp, high-resolution scan of a clean printout OCRs nearly perfectly; a faded photocopy of a photocopy, or a page photographed at an angle under poor lighting, produces more OCR errors that are worth spot-checking before you trust the resulting summary's specifics.

A quick before/after on OCR quality

Two scans of the same paragraph illustrate the range. A clean, flatbed-scanned page at 300 DPI from a modern printout OCRs to something like: "The quarterly report shows a 12% increase in revenue, driven primarily by the expansion into three new markets." Every word correct, punctuation intact, ready to summarize immediately. A poor scan of the same paragraph — photographed at an angle on a phone, under yellow indoor lighting, from a page that had been folded — might OCR to something like: "Tbe quarteriy repert shows a l2% increase in revenue, driven primariiy by tbe expansion Into tbree new markets," with character-level errors scattered throughout (rn/m confusion, 1/l/I swaps, b/h misreads). The second version is still summarizable — a capable summarization model can often infer intent past minor OCR noise — but a number like "l2%" reading as a letter-l instead of a one is exactly the kind of error that's worth a human glance before it ends up quoted as fact in a summary. This is the practical reason step 3 of the workflow above (verify before you summarize) isn't optional busywork — it's the one place an OCR error becomes a summary error if skipped.

When it's genuinely not worth OCR'ing

Not every scanned document is worth this two-step process. A single scanned page you just need the gist of is often faster to read yourself than to OCR, verify, and then summarize — the OCR-first workflow earns its keep on longer documents (10+ pages) where reading the whole thing yourself is the actual alternative being avoided. For a one-page scanned form or letter, skimming it directly is usually the pragmatic choice.