How to Make Scanned PDFs Searchable Across Client Files

To make scanned PDFs searchable, run OCR over the client folder so each image-only page gets an invisible text layer on top of the picture. Work on a copy, skip files that already have text, set the language, then test by searching each file for a payer name. The scans stay as they are; nothing needs rescanning except unreadable pages.

Why scanned client PDFs arrive without searchable text

A scanned client PDF has no searchable text when the device that made it saved a picture of each page and nothing else. Home scanners, phone apps and fax-to-PDF services can all do this. The page looks like a document to a person, but to a search box it is one photograph, so a search for "Harbor Federal" returns nothing.

The OCRmyPDF documentation describes the fix in one line: the tool "adds text 'layers' to images in PDFs, making scanned image PDFs searchable." OCR, short for optical character recognition, is the step that guesses which letters are in the picture. A PDF that never went through OCR has no letters to find.

Several routes into a client folder skip that step:

• A flatbed or sheet-fed scanner set to save straight to PDF, with text recognition turned off or never offered.
• A phone app that captures the page as an image and wraps it in a PDF.
• A fax service that turns an incoming fax into a PDF of page images.
• A printed statement scanned back in, where a digital file was printed, signed or annotated, and then scanned.

Digital files behave differently. A W-2 downloaded from a payroll portal or a statement exported from online banking usually carries real text from the start. A typical catch-up folder mixes both kinds, which is why the next step is sorting them.

Settings for new scans, such as resolution and colour mode, belong at the scanner. The post on scanner settings for tax source documents covers them. This post deals with the scans that already exist.

Finding the image-only files in a client folder before adding text

Finding the image-only files in a client folder means splitting it into files that already contain text and files that are pictures only, without opening all 200. Check one file by hand first so you know what each kind looks like, then let a tool sort the rest by trying to read text from every file.

The file-by-file checks (select text, search for a visible amount, look at the font list) are set out in how to tell a scanned PDF from a digital one. They work well for a handful of files. For a whole folder, use a tool that answers the same question for every file in one pass.

Two folder-level methods work:

1. Let the OCR tool refuse the files that have text. The OCRmyPDF advanced guide says that "if a page in a PDF seems to have text, by default OCRmyPDF will exit without modifying the PDF." Its error reference shows the message, "page already has text!", and notes the tool "can't quite tell the difference" between printed text and an earlier OCR layer. Run it over the folder with default settings and every file that triggers that message has text on at least one page, so it is either digital or mixed.
2. Extract the text and look for empty results. The OCRmyPDF cookbook suggests Poppler's pdftotext or pdfgrep "to extract all text from a PDF, whether generated from OCR or otherwise." A file that produces no text, or only a few stray characters, is image-only.

Either way, write the result down. A short list with three groups (has text, image-only, mixed) is enough. Mixed files, where a client stapled a scanned receipt behind a digital statement, matter most, because a search may find the first page and miss the rest.

How do you make scanned PDFs searchable in bulk?

Scanned PDFs are made searchable in bulk by running one OCR command across every file in the folder, with settings that skip pages already holding text, name the document language and write the output to a separate folder. The routine below uses OCRmyPDF, an open-source tool with documented options for each of those choices.

A five-step bulk routine, with the setting at each step

1. Copy the folder and write to a new one. Create an output/ folder first. The OCRmyPDF batch guide gives the form parallel --tag -j 2 ocrmypdf '{}' 'output/{}' ::: *.pdf, which runs on "all files named *.pdf in the current directory" and writes them to "the previously created output/ folder." The same page warns that "it will not search subdirectories", so run it once per year folder.
2. Fix orientation first. Sideways pages read badly. Add --rotate-pages --deskew, or clean the pages beforehand as described in rotating and deskewing scanned client pages in bulk.
3. Set the language. The cookbook says OCRmyPDF "assumes the document is in English unless told otherwise" and that "OCR quality may be poor if the wrong language is used." For a client with English and Spanish paperwork, the setting is -l eng+spa, and the language packs must be installed.
4. Skip pages that already have text. Add --mode skip. The advanced guide says that with this setting "no image processing or OCR will be performed on pages that already have text," which suits files that are part digital, part scanned.
5. Choose the output type and keep a text copy. OCRmyPDF writes PDF/A by default. Add --output-type pdf for a standard PDF, and --sidecar to save the recognized text as a separate .txt file you can scan by eye.

Put together for one year folder, the example command is:

parallel --tag -j 2 ocrmypdf --mode skip --rotate-pages --deskew -l eng --output-type pdf '{}' 'output/{}' ::: *.pdf

Before and after: one example client folder of 12 PDFs

The table shows a fictional client, the Okafor household, with 12 PDFs for one tax year. The test search used the payer or issuer name printed on each document.

Nine of the twelve were findable after the first pass. The faint receipt and the faxed form need a better copy rather than another OCR run, and the handwritten log needs a descriptive file name, because OCR cannot read handwriting. The duplicate W-2 is still a duplicate after OCR; making it searchable only makes it easier to spot.

Does making a scanned PDF searchable change the original scan?

Making a scanned PDF searchable adds a text layer behind the page image; in the usual settings the visible page is not redrawn by hand or retyped. Some settings do change the image, though, and the file usually grows. Keep the original scan alongside the searchable copy until the copy has been checked.

The OCRmyPDF introduction says the tool rasterizes each page to run OCR, and the resulting text layer "is then integrated back into the original PDF." That is why the picture you see is normally the one the client sent.

Four settings change more than that:

• Deskew and other image processing. The introduction says that when options such as deskew are used, "the OCR layer is integrated into the processed image," so the output shows the straightened page, not the scan as sent. The bulk routine above uses --deskew, which is one more reason to keep the original.
• PDF/A output. The introduction says PDF/A "tends to result in larger files than standard PDFs because it embeds certain resources." It also says that when Ghostscript does the PDF/A conversion, it "may transcode grayscale and color images, potentially lossily."
• Forcing OCR. The cookbook says that when pages are rasterized this way, "the file usually grows and vector content is lost." Use force mode only on files you know are image-only.
• Final cleaning. A cleaning option that writes the cleaned page into the output replaces the image the client sent. The post on cleaning up scanned client documents covers when to use it.

Keeping the original also fits how the IRS describes electronic records: Revenue Procedure 97-22 says an electronic storage system must "index, store, preserve, retrieve, and reproduce" the records, so a searchable copy helps with retrieval but does not replace the scan it came from. The legibility test the same procedure sets for stored scans is covered in whether to compress scanned client documents.

Search terms that find a document in a searchable client folder

Good search terms for a searchable client folder are short, printed in large type, and unique to one document: an issuer name, the last four digits of an account, or a form number. Long phrases, full EINs and amounts make poor terms, because one misread character in the OCR text makes the whole search miss.

Terms that usually work:

• Issuer names, such as "Brightline" or "Northgate." One distinctive word beats the full legal name with "LLC" or "N.A." on the end.
• Account endings, such as "4821." Statements print the last four digits in several places, so one clean read is enough.
• Form numbers, such as "1099-DIV." Try "1099" alone if the hyphen was read as a dash or a space.
• Tax year, combined with a form number, to separate this year's 1098 from last year's.

Terms that often fail:

• Full EINs or SSNs. Nine digits give nine chances for a misread.
• Amounts. A comma read as a period breaks "12,480.00."
• Long phrases. In Preview on a Mac, Apple's guide to finding text in PDFs says "if you type a phrase, Preview searches for that exact phrase." Choosing Any Match from the magnifying glass menu matches any word in it instead.

Searching finds where a document sits. Filing it so it does not need finding is a different job, covered in organizing documents for a multi-year catch-up client, where a folder spanning several unfiled years is sorted by tax year first.

When searchable scanned PDFs return wrong or missing text

Searchable scanned PDFs return wrong or missing text when the page is hard to read: faint thermal receipts, poor faxes, handwriting and dense tables. The text layer is a guess, so treat it as a way to find documents and never as the source of a figure that goes into a return or a ledger.

The OCRmyPDF introduction lists the limits plainly. "It is incapable of recognizing handwriting." The OCR engine "might fail to recognize two columns in a document and attempt to join text across columns." And "the quality of the OCR output depends on the quality of the input." Each of those matches a miss in the example folder of 12 PDFs: the handwritten charity log, the faint daycare receipt and the faxed 1099-NEC.

What to do with each miss:

• Faint or faxed pages. Ask for a better copy or rescan at the settings for tax source document scans. Running OCR again on the same poor image rarely helps.
• Handwriting. Rename the file by hand so its name carries what search cannot.
• Tables. Expect a statement's columns to run together in the text layer. A search for an account ending still works; reading amounts from it does not.

The text layer is not a data source. OCR text alone gives you words with no idea which number is wages and which is withholding; the post on what OCR alone gets you on a client document explains the gap. The figures themselves need checking against the page, and the post on how accurate OCR is on tax forms covers the error rates and checks.

Searchable files help a person find a page. Reading the figures is a separate step: Schema CPA reads each document a client sends, sorts it by type, issuer and period, and exports the data to Excel or CSV, though it does not turn scans into searchable PDFs. The document types it reads are listed on the homepage, and you can get started with a few clients.