Why Scanned PDFs Defeat Every Converter (and What OCR Actually Does)

You dropped a PDF into a converter, hit go, and got back a spreadsheet full of page-sized pictures. Or a Word file with a handful of garbled characters where four pages of text should be. The converter didn't break. Your PDF is scanned, and that one fact changes everything about what any converter can do with it.

This trips up more conversions than any other single cause. A scanned invoice, a contract someone printed and signed and scanned back in, a receipt photographed on a phone, they all carry the .pdf extension and look perfectly normal on screen. But there's nothing inside for software to read. Here's what a scan actually is, why it stops converters cold, what OCR does about it (and what it doesn't), and the order of operations that gets you a usable file instead of a folder of images.

The 10-second test for whether your PDF is scanned

Before you convert anything, run one check. Open the PDF in any viewer and try to select a line of text with your mouse, the same way you'd highlight a sentence to copy it.

If individual words turn blue as you drag across them, the file has a text layer. Converters can read it, and your conversion will almost certainly work.

If your cursor just drags a grey rectangle across the page and nothing highlights, there's no text under the image. What looks like a paragraph is a photograph of a paragraph. Same extension, completely different file, and no converter can pull data out of it until that's dealt with.

That single test predicts the outcome better than anything else you can do. A PDF exported straight from Word, a browser, or online banking is born digital and has real, selectable text. A page that went through a scanner or a phone camera is an image, no matter how crisp it looks.

Why a scanned PDF defeats a converter

Converters work on the text layer, not on the pixels you see. When there's no text layer, they have nothing to grab.

Watch what happens when you feed a scan to a PDF-to-Excel converter. It runs a table-detection library called pdfplumber over each page, looking for text sitting in rows and columns. On a scan it finds none. So it falls back to pulling plain text line by line, and still finds nothing, because there are no characters, only a picture. As a last resort it renders each page as an image, drops that image into a spreadsheet, and writes a note beside it: "This PDF contains images only. For text extraction, use OCR."

That message is the tell. When you try to convert a PDF's tables into Excel and it hands you back page images and a pointer to OCR, that isn't a failure of the tool. It did the only honest thing possible with a file that has no readable text. The same logic holds for PDF-to-Word, PDF-to-text, any of them: no text layer, no conversion.

What OCR actually does (it doesn't edit your PDF)

Optical character recognition is the missing step. OCR looks at the image of a page, recognizes the shapes as letters and words, and writes those characters back into the file as a text layer that sits invisibly on top of the picture.

Here's the part people get wrong. OCR doesn't redraw or tidy up your document. The scan looks exactly the same afterward. What changes is underneath. Select text now and you're highlighting that invisible layer, positioned to line up with the words in the image. Search finds them. A converter can finally read them.

Under the hood, this site runs the scan through Tesseract, the open-source OCR engine Google originally built and released. It renders each page to an image, recognizes the characters, and writes them back in.

Two things OCR does automatically that trip people up

The first: pages that already contain real text get skipped. Run OCR on a document that mixes digital pages with scanned ones and it only touches the image pages, leaving the text pages untouched. That's usually what you want, but it surprises people who expected the whole file to be reprocessed.

The second: tilted pages are deskewed automatically before recognition. A page scanned a few degrees crooked gets straightened first, which meaningfully lifts accuracy, since OCR reads a straight line of text far better than a slanted one. What it can't fix is a page rotated fully sideways or upside down; straighten that yourself before running OCR.

The scanned-PDF-to-Excel workflow that works

Put the pieces in order and the fix is short: OCR first, convert second.

1. Confirm the file is a scan using the selection test above.
2. Run it through OCR to add a searchable text layer with OCR. Pick the document's actual language before you start, because the engine uses language-specific training data and the wrong choice wrecks accuracy.
3. Download the OCR'd PDF and run the selection test again. Text should highlight this time.
4. Feed that version into your converter.

Skip step two and every downstream tool keeps failing the same way, because the input never changed. The converter was never the problem; the missing text layer was.

Why your OCR'd file still has mistakes

OCR is recognition, not transcription, and it guesses. How often it guesses right comes down to the image it was handed.

Tesseract's own documentation says it works best at 300 DPI or higher. Below that, accuracy falls off a cliff. The docs note results drop rapidly as the printed characters get small, and once the lowercase letters shrink below roughly eight pixels tall, most of the text gets thrown out as noise rather than guessed at. A 150 DPI scan, or a phone photo taken at an angle, simply doesn't give the engine enough to work with.

There's a second filter you can't see. This site's fallback recognizer drops any word it isn't reasonably sure about, anything under a confidence score of 30 gets left out instead of guessed, which is exactly why a poor scan comes back with gaps where words should be.

What actually moves the needle:

If a result comes back rough, rescanning the original at 300 DPI fixes more than any amount of retrying the conversion will.

When to skip OCR entirely

OCR is a recovery step, not the goal. The biggest accuracy win happens before any of this: get the born-digital original.

If the document exists somewhere as a real PDF export, from online banking, an email attachment, or whatever system generated it, that file has a perfect text layer and converts cleanly every single time. No recognition, no guessing, no gaps. Tracking down the original beats OCR-ing a scan of it in every case.

Two dead ends to know about. Handwriting is largely a lost cause, since these engines are trained on printed type and cursive in particular comes back as noise. And if your PDF is password-protected, OCR refuses to run until you remove the protection first, because the encryption stops the tool from reading the pages at all.

So the order that saves you an afternoon: run the selection test, and if nothing highlights, stop re-feeding the file to converter after converter hoping one of them cracks it. None will. OCR the scan, confirm the text highlights now, then convert. And any time you can get your hands on the original digital file instead of a scan, take that route and skip the detour entirely. The scan was always the hard way.