No Readable Text Detected After OCR: Six Real Causes

Twelve pages. Four minutes of laptop fan. Then a yellow bar: OCR finished, but no readable text was detected. Try another language or a clearer scan.

The message is honest but broad, and "try a clearer scan" is unhelpful when the scan is the only copy you have. Here are the causes that actually produce an empty result, roughly in the order they turn out to be responsible, and what each one needs.

Zero: check whether you needed OCR at all

Before anything else, open the PDF in any viewer and try to drag-select a line of text. If a blue highlight appears, the file already has a text layer and OCR is the wrong tool — PDF text extract will pull the text out instantly and exactly, with none of the guesswork.

This also runs the other way. If extraction returns nothing on a page that clearly has words, you have confirmed it is genuinely an image and OCR is the right next step.

1. The pages are phone photographs, and they are too small

This is the big one.

PDF OCR renders every page before reading it, targeting roughly 300 DPI — the resolution recognition engines are tuned for. It scales the page between 2× and 4×, and caps the longest edge at 3,500 pixels so a huge page cannot blow up your browser's memory.

But rendering only controls how large the page is drawn. It cannot add detail that was never captured. If someone photographed a document at arm's length and the resulting image inside the PDF is 900 pixels across, blowing it up to 3,000 pixels gives you a bigger blur, not a readable one. Letter strokes that occupy two pixels stay two pixels of information.

Rough guide: a body-text character needs to be about 20 pixels tall for reliable recognition. On A4, that means the page image wants to be at least 1,700 pixels wide, and comfortably more.

Fix: re-capture. A phone scanner app that flattens, crops and boosts contrast beats a raw camera photo by a wide margin. If re-capturing is impossible, export the pages with PDF to images, improve contrast and crop the dead margins in an editor, then rebuild them into a PDF and OCR that instead. Two extra steps, but it is frequently the difference between nothing and a usable draft.

2. The wrong language is selected

Usually a wrong language produces garbage rather than silence — English selected on a Hindi page gives you nonsense Latin words. But when the script is structurally unlike the model and the page is also marginal, the engine's confidence collapses and it returns nothing at all.

Fix: open the language picker and search by native name if you are not sure of the English one. Tick every script genuinely present on the page, and only those. Two is fine. Six is counterproductive.

3. The page is light text on a dark background

Recognition assumes dark ink on light paper. A slide deck exported with a dark theme, a certificate with a deep coloured background, or a form printed on a saturated blue ground can all leave too little tonal separation for the engine to find character edges.

Fix: invert or de-colour the pages before OCR. The same detour as above — pull them out as images, adjust, put them back.

4. The PDF is encrypted

An encrypted file cannot be rendered, so there is nothing to read. Depending on the file this shows up as an error rather than an empty result, but a permissions-only password can produce odd partial behaviour.

Fix: run PDF unlock first and OCR the unlocked copy.

5. It is handwriting

Stated plainly, because it saves people a lot of retrying: the engine reads printed and typed text. It does not read handwriting reliably, and on cursive it does not read it at all.

On a filled-in application form you will typically get the printed labels and the printed instructions back cleanly, and nothing where the answers are. That is not a failure to be tuned around. If the whole document is handwritten, the empty result is the correct result and typing it out yourself is the fastest remaining route.

6. The text is vector outlines, not an image and not text

An uncommon but real case. Some design and print workflows convert every glyph to vector outlines before export, usually so the file will print identically without embedded fonts. The page is not a picture, so it renders razor-sharp at any zoom — but there are no characters in the file either.

You can spot it: zoom to 800% and the letters stay perfectly crisp, unlike a scan, yet nothing selects and text extraction returns nothing.

OCR will actually work on these, because the rendered page is a clean, high-contrast image. If it did not, the problem is elsewhere on this list.

When only some pages come back

Watch the counter under the progress bar — it reports Processed 7 of 12 pages as it goes, and the text box fills in page by page with --- Page N --- markers. If pages 1 to 5 produce text and 6 onward are empty, you are not looking at a tool failure. You are looking at a document where the second half was scanned differently: a different session, a different machine, a lighter setting.

Treat those pages separately. Extract them, improve them, run them on their own, and paste the result into the text box alongside the rest before downloading the Word or TXT file.

Slow, then killed

Everything runs on your own device. A 100-page scan on a mid-range phone will take a long time and may be terminated by the browser before it finishes, which can look like a failure rather than a memory limit.

Practical steps: close other heavy tabs, do it on a laptop if you have one, and split very large documents into 20 or 30 page sections. The per-page work is the same; it is holding all of it at once that hurts.

A short checklist

If you have tried everything

There is a heavier option. Advanced OCR accepts JPG, PNG and WebP as well as PDF, and applies more aggressive preprocessing and multiple recognition passes on difficult pages, with limits that adapt to what your device can handle. It is slower by design. On a faded carbon-copy or a badly lit photo, it is sometimes the one that gets something back.

The full set of recognition tools is under Scanners if you want to compare them side by side before committing another six minutes of processing.