Convert Scanned PDF to Searchable PDF Python Scripts

Yes. A short Python script can convert a scanned PDF to a searchable PDF by handing each file to an open-source OCR tool and saving what comes back. The code is the easy part. A firm that scripts the job also takes on the installation, the settings, the checking and the logs.

This post is for the lawyer or manager deciding whether to let a litigation-support person build such a script, and for that person when asked what it would involve. It describes the named tools only from their own documentation and makes no claim about how well any of them reads a page.

Agree on the test pages before anyone writes the script. Search the output for a party name, a docket number, a Bates number, and a line from a circuit court motion. Compare those hits with the page image yourself. A caption the picture shows and the text misses should be logged by file and page.

Can a Python script convert a scanned PDF to a searchable PDF?

A Python script can do it, but Python does not read the page. The script calls a separate OCR program, passes it the scanned PDF, and receives a PDF with a text layer added. The script's own work is the loop around that call: which files, in what order, saved where, and what to do when one fails.

That division matters when you scope the task. The recognition comes from an engine installed on the machine, and the post on what an OCR engine is explains that layer. The script is plumbing.

The documentation for OCRmyPDF shows how small the central call is. Its page on using the OCRmyPDF API gives this as a complete example of the older calling style:

import ocrmypdf

if __name__ == '__main__':  # To ensure correct behavior on Windows and macOS
    ocrmypdf.ocr('input.pdf', 'output.pdf', deskew=True)

Everything a firm cares about lives outside those lines: keeping the received file untouched, naming the output, recording what happened, and testing the result.

What the open-source OCR tools say they do, in their own documentation

Three open-source projects a programmer can build this job on are Tesseract, pytesseract and OCRmyPDF. Each describes itself in its own documentation, quoted here. Read the current pages before you build on them, because options and defaults change between versions.

Tesseract. The Tesseract user manual says the engine "can be used directly via command line, or (for programmers) by using an API to extract printed text from images", and that it "doesn't have a built-in GUI". Its command line usage page shows a searchable PDF output and describes the result as "a pdf with the image and a separate searchable text layer with the recognized text". The input in that example is an image file, not a PDF.

pytesseract. The pytesseract project page describes the package as a wrapper for the Tesseract engine and lists a function, image_to_pdf_or_hocr, with an example commented "Get a searchable PDF". It also works from an image, and it requires Tesseract to be installed separately.

OCRmyPDF. The OCRmyPDF introduction says the tool "uses Tesseract, a widely available open source OCR engine, to perform OCR", rasterizes each page, runs recognition on the image, and integrates the resulting layer "back into the original PDF". The same page lists limitations it inherits from Tesseract, among them that it "is incapable of recognizing handwriting", that it "may detect gibberish and report it as OCR output", and that Tesseract "may struggle to analyze the natural reading order of documents". It also notes that the tool defaults to producing PDF/A output, with an option for a standard PDF.

The practical difference is the input. A scanned PDF given to the first two must be turned into page images first and reassembled afterwards, which is more code and more places to lose a page. The third accepts the PDF directly.

When does scripting searchable PDFs make sense for a law firm?

Scripting makes sense when three things are true at once: the volume is large and recurring, someone on staff can write and support the code, and the firm is willing to check the output itself. Take away any one and a tool with a person at the controls is the safer choice.

Count the real cost. The software has no licence fee, but the hours to install it, test it on the firm's own documents, write the checks and keep it running are paid in salary. Read the licences too: the OCRmyPDF introduction tells users to "ensure they comply with OCRmyPDF's licenses and the licenses of all dependencies".

If nobody on staff programs, the post on how to make a PDF searchable for free covers no-cost routes that need no code. If the job is a single folder, the post on bulk OCR for PDF files covers the planning, whichever tool does the work.

Who maintains the script, and what a silent failure looks like

Name an owner and a backup before the first production run. A script fails silently when it finishes without an error and leaves some files unconverted, so the owner's job is less about writing code than about reading the log and testing the output after each run.

OCRmyPDF's own example shows where quiet skips come from. The batch script on its batch processing page catches several conditions and writes a log line for each instead of stopping: a document skipped "because it is encrypted", one skipped "because it already contained text", and one skipped "because it has a digital signature". A script written that way completes normally while a share of the folder remains unsearchable. Nobody will know unless they read the log. A skip for a digital signature is a decision about how to make that signed PDF searchable, not a file to force through.

Give the owner this list.

• One log row per file: name, page count in, page count out, result, and the reason for any skip.
• A count at the end: files found, converted, skipped, failed. The four numbers must reconcile.
• Never write over the input. The output goes to a separate folder under a distinct name.
• A sample test after every run: open a set number of outputs and search for a word on a middle page.
• Pinned versions: record the version of each tool, and retest on sample files before upgrading.
• A written runbook that the backup person has followed at least once.

Running the conversion on the firm's own machine: what that settles and what it does not

Running the tools locally means the documents are not sent to an outside OCR service for this step. That settles one question about third parties. It does not settle who can reach the machine, where temporary files and logs end up, or whether the files being opened are safe.

Three limits are worth stating to whoever approves the project.

• The machine is now the system to secure. Its disk, its backups, its user accounts and the folder the script writes to all hold client documents.
• Logs and temporary files contain client material. File names in a log can reveal matters and parties. Decide where logs live and when they are deleted.
• Incoming PDFs are untrusted input. The OCRmyPDF page on PDF security says the tool "should only be used on PDFs you trust" and "is not designed to protect you against malware".

A local script and a hosted converter are two ways of meeting the same responsibility for client documents, and a firm can use both. Schema Law is the hosted kind: you upload a PDF, PNG or JPEG of up to 20 MB in the browser and export a searchable PDF, with the commitments the site makes listed in the security section of the homepage. Whichever route you choose, the test of the output is the same: open the file and search for a word you can see.