← All posts

Which pages of your PDF actually need OCR?

The bundle is two hundred pages. You search it for a name that is printed, in ink, on page 147, and the search box tells you there are no matches.

Somebody says run OCR on it. Fine — except every page you can find explains how to OCR a PDF, and that was never the part you were stuck on. Most of this document is an ordinary typed report that searches perfectly well. Somewhere in the middle of it are a few scanned exhibits, and those are the pages doing the damage.

Recognition is not free. It takes real time per page, bureaux bill by the page, and run over a page that already has good text it makes that page worse rather than better. So the useful question is which pages, and it takes about a minute to answer.

Why one PDF ends up half scan and half text

A PDF has no property that says "this is a scan". It cannot have one, because being a scan is a fact about a page rather than about a file.

Every page is an independent object carrying its own list of drawing instructions, and a typed page carries thousands of them where a scanned page carries one that draws a picture — which is the whole reason a converter finds no words in a scan. Nothing above the page level distinguishes the two, and nothing needs to: when documents are combined, pages are copied across exactly as they are. Merge PDF does that, and so does every other merge worth using: no page is re-rendered, so each one keeps whatever it already was.

Which is how perfectly normal documents end up mixed, usually without anyone deciding to make them that way:

The report at the front searches. The three exhibits at the back do not. Both facts are true of the same file, which is why every answer that treats the document as a single thing — including the tooling written for sorting whole folders — answers a question you did not ask.

What "does this page need OCR" actually tests

Two questions per page, in order.

How many characters does the page yield? Read the text out of the page's content stream, throw away every space and line break, and count what is left. A dense page of A4 prose comes to somewhere between 1,500 and 3,000 characters. A scanned page comes to zero, because there are no text-drawing instructions on it at all.

If it is near zero, does the page draw a picture? This is the question people skip, and it is what separates the two ways a page can be silent. The check walks the page's resources looking for an image, following any nested form objects down as well, since a scan is often wrapped a layer or two deep. If there is an image, the page is a picture of something and recognition has something to look at. If there is no text and no image, the page is genuinely empty — the back of a duplex sheet, usually — and OCR will find nothing there because there is nothing there.

That is the whole method, and it is why the answer arrives as three lists instead of a yes or no. Pages that already carry real text. Pages that are pictures. Pages that are blank. Only the middle list is worth paying to recognise, and on a typical bundle it is short.

Why the bar is twenty characters, and when to move it

Setting the bar at "more than zero characters" seems obviously right and fails immediately on a real bundle. It fails in a specific way worth knowing about.

Scanned pages routinely carry a handful of characters that were added after the scan, as real text, on top of the picture: a page number stamped on by whatever assembled the bundle, a Bates number in the corner, a "CONFIDENTIAL" stamp, a header applied by the scanning software. Those are perfectly genuine text instructions. Count anything above zero as a text layer and every stamped scan in the document reports as searchable while remaining completely unsearchable.

So OCR PDF counts non-whitespace characters and puts the default bar at twenty: comfortably more than a stamp, and a small fraction of any page that is actually made of words. Move it when your document tells you to.

The report also gives you the total character count across the pages where it found text. Divide that by the number of those pages. If the average comes out at forty characters, none of the "text" pages is really a text page and the whole document is a scan wearing stamps.

Working out which pages, in order

  1. Look at the file in the browser first, if it is confidential. Our PDF inspector opens the PDF locally — nothing is uploaded — and prints a per-page table with a character count against every page number. Any page reading 0 is a candidate. It does not do the picture test, so it cannot tell a scan from a blank sheet, but for a sensitive bundle it is often all you need and it never leaves your machine.
  2. Narrow the range if you already know roughly where the trouble is. Checking pages 140-160 gives you an answer you can read, rather than a list covering two hundred.
  3. Run the check and read the three lists, adjusting the character bar per the section above if the results look implausible.
  4. Open two of the surprises. A photocopy of a printout looks exactly like a printout until you try to select a word on it. If every page comes back silent, be suspicious: being a picture is only one of four reasons a PDF will not give up its words, and recognition fixes none of the other three.
  5. Write the page list down. It is the input to everything that follows, and it is also your check afterwards: the same pages should come back reporting real text once recognition has run.

Recognising only the pages that need it

With the list in hand there are two routes, and which one you want depends on who is doing the work.

If you are running it yourself, do not extract anything. Point OCRmyPDF at the whole file with --skip-text, which leaves every page that already has text exactly as it is and recognises the rest:

ocrmypdf --skip-text --language eng in.pdf out.pdf

Add --pages 147-149 to confine it further when the file is large and you only want those three pages touched. What you must not use here is --force-ocr: it rasterises every page first, which throws away the good text layer on the 197 pages that were fine. Your page list is how you check the result — run the check again on the output and the picture list should be empty.

If the pages are going to a bureau, or anywhere that bills per page, pull them out first. Extract PDF pages copies a range like 147-149 into its own document and leaves the original alone; Merge PDF puts the recognised version back afterwards. Scattered pages make that reassembly fiddly, so check the page order before you delete anything.

Either way, straighten before you recognise rather than after. The order is settled in one direction only, and why it is settled is worth the five minutes before you spend anything on recognition. If the destination is Word rather than a searchable PDF, the whole sequence changes shape.

Three ways the check reads a page wrongly

It is a heuristic over drawing instructions, not an understanding of the page. Three cases are worth knowing before you trust a list of two hundred.

Vector line art reports as blank. A CAD drawing, an exported chart, or any page whose lettering was converted to outlines draws no image and says no words, so it lands in the empty list. In the first two cases OCR would indeed find nothing. In the third it would find plenty — the labels are there, drawn as shapes. If your document contains drawings, look at the blank list rather than believing it.

A page already recognised badly reports as text. The check counts characters; it does not read them. A scan recognised at 180 dpi with the wrong language pack has two thousand characters of confident nonsense on it and sails into the searchable list. If a page insists it has text and your search still fails, run PDF to text over that page and read the output. Real prose is obvious; so is rubbish. That tool also refuses outright when the pages you gave it hold no text at all, and tells you how many pages came back empty, which makes it a second opinion on the picture list.

Doing the whole thing on your own machine

If the file cannot be uploaded anywhere, poppler's pdftotext gives you the same answer offline. It takes a page range, so one loop produces the list:

for p in $(seq 1 200); do
  n=$(pdftotext -f $p -l $p in.pdf - | tr -d '[:space:]' | wc -c)
  [ "$n" -lt 20 ] && echo "page $p: $n characters"
done

That is precisely the check described above, with the same twenty-character bar, and you can change the number in the last line. pdffonts -f 3 -l 3 in.pdf is the quick confirmation on a single page: a page that draws text lists at least one font, and a page that lists none is drawing a picture.

Neither does the image test, so neither separates a scan from a blank sheet. On a duplex-scanned bundle, where half the silent pages are the backs of sheets, that is the distinction that stops you sending a hundred blank pages through a recogniser.

What the list is actually worth

The honest answer to "how do I OCR this PDF" is usually "you do not". Eleven pages need recognition and 189 need to be left alone — a second, guessed copy of the words underneath a good one gives you a document that matches every search twice and hands back whichever version it feels like.

A minute with the page list turns that into eleven pages and one command, and leaves the other 189 exactly as their author wrote them.

Tools this post uses: