Scanned PDF vs text PDF: why some documents convert and others return nothing
The single most common support question about PDF conversion is some version of "I dropped in my PDF and got an empty file." In almost every case the PDF is a scan: photographs of pages wrapped in a PDF container, with no text inside at all.
This article explains the two kinds of PDF, a two-second test that tells you which one you are holding, why the absence of OCR in a converter is a design decision rather than a gap, and the exact workflow that turns a scanned document into Markdown anyway.
Every PDF is one of two kinds
A text-based PDF carries a text layer: characters stored as character codes with font and position information, the way a word processor would emit them. Documents exported from Word, LibreOffice, Google Docs, LaTeX, or most reporting software are text-based, even if they contain images too.
An image-only PDF is a sequence of page photographs, wrapped in the PDF format. Scanners produce these, as do phone scanning apps, fax-to-email gateways, and the photocopy machines that email documents to themselves. The pixels are all there is; there are no characters inside.
The confusion is understandable because the two are indistinguishable to the eye. A scanned PDF opens in a reader, displays crisp text, supports zoom — and contains not a single character code. The text you see is a picture of text.
The two-second test
Open the PDF in any reader and try to select a sentence with the mouse. If the selection highlights words and you can copy them into a text editor and get real text back, the PDF is text-based and any converter will read it.
If clicking and dragging draws a rectangular screenshot-style selection box instead of highlighting text, the PDF is a scan. Nothing is selectable because nothing selectable exists. The copy command produces nothing for the same reason.
File size is a rough secondary signal: a ten-page text PDF is often under a megabyte, while a ten-page 300-dpi scan is often tens of megabytes. The selection test is definitive, though — size varies too much with image compression to be trusted alone.
Why no converter can skip OCR
A converter reads what the file contains. For a text-based PDF that means character codes, which map cleanly onto Markdown text. For an image-only PDF it means pixels, and pixels are not text in any sense a Markdown writer can emit.
Bridging that gap requires optical character recognition: a model that looks at the image of each glyph and guesses which character it depicts. OCR is a large, specialized domain — language models tuned per script, layout analysis, confidence scoring — and bolting a mediocre one into a converter produces text that looks plausible and is wrong in exactly the places that matter: numbers, names, and legal terms.
That is why this site's converter reads text layers and declines to guess at pixels, telling you which pages have no extractable text instead of handing over a confident-looking document full of recognition errors. A wrong document is more expensive than a refused one.
What OCR actually does, and where it fails
OCR software segments a page image into lines and words, classifies each word's characters, and writes a new, text-based PDF or plain text output — often with the original image kept for display and the recognized text layered invisibly on top. Desktop tools like Adobe Acrobat's OCR, or the open-source ocrmypdf built on Tesseract, do this well.
Its failure modes are consistent across engines. Visually confusable glyphs — capital I, lowercase l, digit 1 — misclassify in ways spellcheck cannot catch. Recognition quality drops on low-resolution scans, skewed pages, faint photocopies, and handwriting. And tables are the worst case again: OCR reads cell text in reading order but reconstructs none of the grid.
Language matters too: recognition models are script-specific, and mixed-language documents degrade on the minority language. None of this makes OCR useless; it makes OCR output a draft that deserves the same verification you would give a converted table.
Why this tool refuses to guess
When the converter meets a page with no text layer, it does not return garbage, and it does not return nothing either — it tells you. The conversion result includes a warning listing the page numbers that appear to need OCR, and if the entire document has no text, the error says so plainly.
This is the honest contract for a local tool: precise about what it read, explicit about what it could not. Silent partial output, the alternative, is how a missing chapter ends up published or an unsigned contract gets filed as complete.
The design also keeps the tool small and fast. OCR models for even one script would dwarf the parsing engine itself, and shipping them in the browser would multiply download size for a capability that desktop software already performs better.
Fixing a scanned PDF first
The workflow for scanned documents is OCR first, conversion second. Run the file through your OCR software of choice — Acrobat's built-in recognition, ocrmypdf on the command line, or a phone app's export with recognition enabled — and it produces a searchable, text-layered PDF.
Then convert that output. The conversion step and the recognition step have independent quality, and keeping them as separate, inspectable stages means you can verify the OCR result in a text editor before anything downstream consumes it.
One caution: choose OCR settings that keep the original page image and add the text layer, rather than re-rendering the pages, so the searchable PDF stays faithful to the scan. After that, the usual conversion quality advice applies, with one addition — OCR'd tables need the same spot-checking as any converted table, doubly so because recognition errors and structure errors can compound.
Mixed PDFs: the partial result
Real-world documents are often hybrids: a text-based report with a scanned signature page, a contract with a photocopied annex, a paper with scanned figures inline. Conversion handles these page by page — text pages convert, image pages produce nothing and get flagged in the warnings.
Read the warning list before reading the output. It tells you exactly which sections of the document are absent, so the partial result can be merged with separately OCR'd pages rather than mistaken for the whole document.
That hybrid case is the strongest argument for the warning-based design: the tool does not decide for you whether eighty percent of a document is enough. It reports the boundary precisely and leaves the judgment, and the OCR step, where it belongs — with you.