How to Make a PDF OCR Searchable When the First Run Failed

When OCR ran and the PDF still will not search, the run either wrote no text into the file you now have open or wrote text that does not match the page. To make a PDF OCR searchable, work out which of five causes applies, then run recognition again on a copy with that cause removed.

A second run with the same file, the same tool and the same settings gives the same result. The work is in the checks before the rerun: confirming which file you are looking at, finding the pages that came back empty, and deciding what to change. This guide follows that order.

On the rerun, search a page that failed before for a word you can see there, such as a party name, a Bates number, or the title motion to dismiss. Compare the hit with the page image. Also search a page that already worked, the complaint caption with the plaintiff and the docket number, and confirm that line still matches the picture.

Why is a PDF still not searchable after OCR ran?

A PDF stays unsearchable after an OCR run for one of five reasons: you opened the wrong file, the tool skipped pages that already held text, the engine could not read some pages, the export was a different format, or the file is fine and the program searching it is at fault.

Sort the failure before you fix anything. Each cause leaves a different trace, and a few quick observations separate them.

The last row is a different problem with a different owner. If you can drag across a sentence, paste it into a blank document and read it correctly, the text layer exists and is sound. The post on PDF search not working separates a faulty file from a faulty program and covers previews, browser tabs and reader options.

One more distinction saves time. A search that finds most words and misses a few is a recognition-quality problem, where a letter or digit was misread. This guide is about runs that leave whole pages or whole files with nothing to find. For scattered misses, read the section on why search still misses words after OCR.

Three observations that sort the failure

1. Select a word on page one, on a middle page and on the last page. Note which pages allow it.
2. Read the file name and the modified time in the title bar and in the folder. Compare them with the time you ran OCR.
3. Look at the file extension of what the tool gave you.

Write the three answers down. Together they tell you which of the five causes you are dealing with.

Did you save the OCR result, or reopen the original scan?

Check first whether the PDF on your screen is the OCR result or the original scan. It is the cheapest cause to rule out. An OCR run produces text only in the file it writes. If that file was never saved, was saved somewhere unexpected, or sits beside an identically named scan, you are still looking at the picture-only original.

Four versions of the mistake account for the confusion:

• The run finished in memory and the program closed without a save. A desktop editor that recognizes text inside an open document changes the open document. Until you save, the file on disk is unchanged.
• The output went to a different folder. A tool that writes results to a default output directory, a downloads folder or a "processed" subfolder leaves the original exactly where it was. You reopen the original from the matter folder and see no change.
• Two files share a name. A download named the same as the scan becomes Order (1).pdf in a downloads folder while Order.pdf in the matter folder stays untouched.
• The email attachment was opened again. Opening the attachment from the message opens the scan as it was sent, however many times you have converted a saved copy.

How to tell which file is open

Compare three facts about the open file with what you expect from the output.

A size that matches the scan to the byte is strong evidence that you are looking at the scan. Adding text changes the file, so two files of identical size and date are the same file under two names.

A worked example

A paralegal at a small firm receives Calloway_Lease.pdf from a client, runs it through a converter in the browser, and downloads the result. The browser saves it to Downloads as Calloway_Lease.pdf. She then opens the file from the matter folder, where the client's attachment was saved that morning. Search finds nothing. The modified time on the open file is 9:12, and the conversion ran at 11:40. The searchable file was in Downloads all along.

The repair is a naming habit. Save every OCR output under a name the scan cannot have, such as Calloway_Lease_ocr.pdf, and move the scan into a subfolder called as-received before you start. Then no folder holds two files that could be confused.

Pages an OCR run skips because they already hold a little text

Some OCR tools leave a page alone, or stop the whole job, when the page already contains any text at all. A scanned page with one line of real text on it, such as an added page number, counts as a text page to such a tool, so the scanned body of the page never gets read.

The documentation for OCRmyPDF, an open-source tool, describes this behavior plainly. Its page of common OCRmyPDF error messages explains that the error "page already has text" appears when the file "already contains printable text or a hidden OCR text layer (it can't quite tell the difference)", and it lists three options for going ahead: one that skips text pages and copies them "without modification", one that removes existing OCR and runs it again, and one that forces recognition on every page. Other programs have their own rules. Read your tool's documentation for how it treats a page with existing text, and if it does not say, test on a copy.

Where the small amount of text comes from

The line of text that blocks a page is easy to overlook because it looks like part of the scan. Look for these:

• A Bates number, exhibit sticker or page number applied by PDF software after scanning.
• A header or footer added by a filing system, a fax service or a document management system.
• A typed annotation, a text box or a filled form field that was merged into the page.
• A cover page saved from a word processor in front of scanned pages.
• A weak text layer the copier wrote at scan time, covering only part of the page.

How to confirm it

Go to a page that will not search. Press Ctrl+A (Command+A on a Mac) to select everything on it, copy, and paste into a blank document. If the paste contains only DEF000412 or Page 7 of 30, the page holds a sliver of real text and a full-page picture. That is the pattern this section describes.

What to do about it

You have three choices, and the right one depends on where the file is going.

1. Use the tool's setting for existing text. If your program has an option to recognize text on pages that already contain some, or to replace an existing layer, turn it on and rerun on a copy.
2. Go back one step in the file's history. If you still have the scan from before the numbers or headers were applied, run OCR on that file, then reapply the numbering.
3. Use a tool that reads every page as a picture. A converter that reads each page image without regard to existing text avoids the skip. Check the output for doubled text afterwards by pasting a page into a blank document.

If the program you are using is Acrobat, the Adobe pages do not say how it treats a page that already holds text; the section on when Acrobat refuses to recognize text on a page sets out what Adobe documents and what you need to test.

Blank-looking, sideways and faint pages that come back with no words

An engine returns no words for a page when it finds nothing it can recognize as lines of print. Three kinds of page produce that result in a file that is otherwise fine: pages that are nearly empty, pages lying on their side or upside down, and pages whose print is too pale to separate from the paper.

Blank-looking pages. A page with a single signature, a received stamp or a handwritten note has little or no print to recognize. An empty result there is correct. The page is not broken, and no rerun will add words that are not printed on it. Note the page and move on.

Sideways and upside-down pages. A wide table scanned in the same pass as upright letters lies on its side in the file. Whether an engine turns it before reading depends on the tool and its settings. OCRmyPDF's documentation, for one, describes an option that "attempts to determine the correct orientation for each page", and its cookbook entry on rotating pages says the default threshold is conservative enough that on some files it may not attempt rotations at all. So do not assume rotation happened. Look at the dead pages. If they are the sideways ones, you have your cause.

Faint pages. Carbon copies, late-generation photocopies, thermal fax paper and pencil give the engine gray marks on a gray field. The page reads fine to you because your eye fills in what the scan lost. The post on OCR for a low-quality PDF covers judging and improving such pages.

Two further cases look like the same failure:

• White print on a black background, as in a printout from microfilm, can defeat an engine that expects dark print on a light page. The post on OCR for microfilm prints covers negative images.
• A photograph of a page with a strong shadow or a steep camera angle can leave only part of the text in readable shape.

Listing the dead pages

Do not guess which pages failed. Walk the file once and record them.

1. Open the OCR output and go to page one.
2. On each page, press Ctrl+A. A page with text shows highlighted words. A page without text shows nothing highlighted, or one box around the whole picture.
3. Write the page number and what you see on it: sideways, pale, picture, stamp only.

The list tells you whether the failure has one cause or several, and it becomes the test for the rerun: those are the pages to check afterwards.

How do you make a PDF OCR searchable on the second attempt?

Change one thing that matches the cause you found, run recognition on a copy, and test the pages that failed the first time. A rerun that changes nothing repeats the failure, and a rerun that changes five things at once leaves you unable to say which change mattered.

Follow this procedure.

1. Start from the right file. Use the earliest clean copy you have: the scan as received, before any numbering, stamping or previous OCR. Copy it to a working folder and leave the received file untouched.
2. Repair the pages on your list. Rotate sideways pages upright in a PDF editor and save. If you hold the paper, rescan the faint pages at a darker setting and swap them in. Leave pages that are correctly empty alone.
3. Set the tool for the cause. For pages skipped because of existing text, choose the option that recognizes or replaces text on such pages. For a file in another language, set that language if the tool asks for one.
4. Check the file against the tool's limits. An upload that exceeds a size or page cap can fail or stop early. Schema Law accepts a PDF, PNG or JPEG of up to 20 MB, and each plan caps the pages in one document; the pricing page lists the caps.
5. Run it and choose the searchable PDF output by name. Read the export or save dialog before you click.
6. Save under a new name. Add _ocr2 or the date so the second attempt cannot be mistaken for the first.
7. Test the pages that failed. Open the new file, go to each page on your list, and search for a word you can see on it.
8. Test three pages that worked the first time. A changed setting can fix one page and harm another.
9. Record the outcome. A line in the file note is enough: which file was the source, what you changed, which pages remain unreadable.

When the second attempt also fails

Stop after two attempts with the same tool. A third run with the same engine on the same pages has no new information to work with. Your choices at that point are a different tool, a better copy of the document from whoever sent it, or accepting that certain pages are not searchable and saying so in the file note.

A browser converter gives you a quick independent test. In Schema Law you upload the file, each page is read into text and tables, and you can look at the parsed result page by page before exporting. If a page on your list comes back empty there as well, suspect the page before the tool. The homepage says recognition is strongest on clean print and weaker on faint faxes, stamps over text and handwriting, and that nothing marks a passage as uncertain, so read the pages on your list against the scan. The how it works section shows the three steps.

When the export was Word or plain text and never a searchable PDF

OCR can finish correctly and still leave your PDF unsearchable, because the tool handed the text back in a different file. A Word or plain-text export holds the recognized words, but the PDF you started with has not changed. Only an export or save labeled as a searchable PDF puts the text into a PDF.

This is easy to miss when a tool defaults to an editable format or when a colleague ran the conversion and sent you "the OCR". Check what you received:

The last row deserves attention. Saving the Word export as a PDF produces a file that searches, and it is tempting to call the job done. That file is a new document made from the recognized text. If the engine misread a figure, the PDF now shows the misreading as if it were the original, and nothing of the signed page remains to check it against.

Getting the right output without starting over

In a tool that keeps the recognized document, you do not need to run OCR again. Open the document and export it once more in the PDF format. Schema Law lists eight export formats, and the one for this job is Searchable PDF, described on the formats section of the homepage as your original file with a hidden text layer. Every plan includes all eight, the free plan among them.

If the tool has discarded the session, rerun the conversion and pick the searchable PDF output at the export step.

Keeping both files is reasonable when you need to search the record and also reuse its language. The post on making scanned documents searchable and editable explains how to keep the pair together so that nobody cites the working copy as the record.