Bulk OCR PDF Folders: Making a Whole Matter Searchable

To bulk OCR PDF files in a folder, list every file first and sort it into three groups: no text, some text, and all text. Run OCR only on the first two, write the results to a copy of the folder tree under the same names, then sample the output and keep a log of what was done.

The recognition is the easy part of a bulk job. The work that protects you is the list you make before the run and the record you keep after it, because a folder of several hundred files gives a silent failure plenty of places to hide.

From the files you open after the run, search a party name, a Bates number, and the title you expect, such as a motion, a deposition, or a default judgment. Include a page near the end and compare the hit with the page image. A dismissal that fails in one subfolder and works in the next shows the run skipped a batch.

What is bulk OCR on PDF files, and when is it worth setting up?

Bulk OCR means running text recognition over a whole set of PDFs as one job, with the same settings, and without opening each file by hand. It is worth setting up when the files are too numerous to convert one at a time and you need to trust a search across all of them.

A matter folder is the plain example. Over two years it collects PDFs saved from Word, scans from the office copier, client documents photographed on a phone, records from third parties and court orders downloaded from a docket. Some are searchable and some are pictures. A search of the folder finds text in the first kind and silently skips the second, so the answer to "where is the letter that mentions the easement?" depends on how each file happened to be made.

A threshold you can apply

There is no fixed number. Weigh these instead:

• How many files have no text? Find out with the inventory before deciding. A folder that looks like a bulk job may turn out to hold a dozen scans among hundreds of typed PDFs.
• Will you search across the set, or only open known files? If people only ever open files by name, searchability matters less.
• Is the set still growing? A one-time cleanup of a closed matter differs from a live folder that receives scans every week. For the second, fix the intake so new files arrive searchable.
• What does a missed document cost? A folder searched for a privilege review or a limitation date justifies more care than an archive nobody consults.

What bulk OCR is not

It is not a discovery production workflow. A production has Bates ranges, a specification from the other side and load files, and the post on batch OCR for discovery covers that, including how a batch should be split before upload. This guide is about your own working folders.

It is also not a reason to convert the only copy. Every step here assumes the folder as it stands is preserved and the run writes to a second location.

Finding which PDFs in a folder still need OCR before a bulk run

Build an inventory: one row per PDF, with its path, page count, size and whether it has a text layer on none, some or all of its pages. Only the files in the first two groups need OCR. The inventory also tells you how many pages the run will consume.

Making the list

Start with a listing of every PDF under the matter's top folder, including subfolders. Your document system or operating system can export a file listing, or a litigation support colleague can produce one with a script. Put it in a spreadsheet with these columns:

Deciding the text status

For a handful of files, open each one and search for a word you can see on a late page. For hundreds, that is too slow, and a tool has to report which pages carry text. The method for checking a whole set, and for spotting a text layer that exists but holds no real words, belongs to the guide on how to check if a PDF is searchable.

Two signs help you triage by eye while the list is being built:

• Size per page. Divide size by pages and sort by the result. Scans, which store a picture of every page, gather at the heavy end of the sheet. The checking guide explains how to read that figure under checking a whole folder of PDFs for searchability.
• Source. Files your own office saved from Word are typed. Files named by a copier are scans, with or without text depending on how the copier is set.

Neither sign is proof. A scan with a text layer and a scan without one are close in size.

What the inventory tells you

Take a fictional matter, Pemberton Orchards v. Lyle Irrigation, with 640 PDFs in 23 subfolders. The inventory shows 410 files with full text, 185 with none and 45 partial, where a typed letter sits in front of scanned enclosures. The 230 files that need work hold 6,900 pages. That figure is the size of the job, and it is a third of what a run over everything would have been.

Look at the outliers too: files with zero pages or that will not open, files that ask for a password, and files over your tool's size or page limit. Mark those for review by hand. A password-protected file stays out of the run until whoever set the password provides an open copy.

Should a bulk OCR run skip PDFs that already have text?

Skip the files that are fully text already. Their text came from the program that wrote them and is exact, and OCR could only replace it with a guess. For partly searchable files, process only the pages without text. Redo a file's text only when you have tested the existing layer and found it bad.

Tools give you up to three behaviors, under different names:

The OCRmyPDF project documents all three, which makes its notes on OCR processing modes a useful reference for the differences even if you use another tool. By default it exits without modifying a PDF when a page seems to have text. In its skip mode, "no image processing or OCR will be performed on pages that already have text." Its force mode rasterizes every page.

Force is the mode to keep away from a bulk run. Forcing OCR across a matter folder would turn every typed brief into pictures of itself, with recognized text standing in for exact text. Never run force over a whole folder. The post on OCR for PDF documents sets out the reasoning under whether to run OCR on a PDF that already has a text layer.

What skip cannot see

Skipping by "has text" has blind spots:

• A junk layer. A scan that a copier already recognized badly counts as having text and is skipped. Find these by testing a sample of the "full text" group that came from scanners.
• A typed page with a pictured exhibit inside it. The page has text, so it is skipped, and the words in the picture stay unsearchable.
• A header-only layer. A scan with a typed Bates stamp or an electronic filing banner on each page has a little text and may be treated as done.

Use the Source column to split the "full text" group. Files saved from an office program can be skipped without a second look. Scans that claim to have text deserve a test before you decide between skip and redo.

Keeping file names and subfolders intact through a bulk OCR run

Write the output to a separate copy of the folder tree, with every file under the same relative path and the same name. Nothing in the original tree is changed. When the run is checked, you decide whether the searchable copies replace the working files or sit beside them.

A matter folder's structure is information. Links in emails, entries in a document index and a colleague's memory all point to paths. A run that drops every output into one flat folder, or renames files to a job number, breaks all three.

Rules for the run

1. Copy, then run. Duplicate the whole tree to a working location, or point the tool at an output root. Never choose an overwrite or in-place option on the only copy.
2. Same relative path in, same relative path out. Correspondence/2024/Lyle_letter_03.pdf in the source becomes Correspondence/2024/Lyle_letter_03.pdf under the output root.
3. Carry the skipped files across unchanged. The output tree should be complete, so the files you skipped are copied as they are. Otherwise the new tree is missing most of the matter.
4. Do not add suffixes inside a mirrored tree. A suffix such as _ocr helps when both versions live in one folder. In a mirror it only makes names differ from the index.
5. Watch for name collisions. If your tool cannot keep subfolders and you must flatten, two files called Scan.pdf from different folders will overwrite each other. Put the folder path into the name first.
6. Mind the dates. A converted file gets a new modified date. If people sort the folder by date, record the original dates in the log.

When the tool takes uploads, not folders

A browser tool has no view of your subfolders, so the inventory does the bookkeeping. Upload the files marked OCR, download each export, and save it at the path in its row.

With Schema Law, check three numbers against the inventory before you begin: an upload can be up to 20 MB, the Free, Solo and Team plans each cap the pages in one document, and each paid plan has a monthly page allowance. Every plan lets you upload several files at a time. The pricing page has the current limits. In the Pemberton example, 6,900 pages fits inside one month of the Team plan's 10,000-page allowance, with room to rerun failures.

If a colleague is going to drive the job from the command line instead, the post on converting scanned PDFs to searchable PDFs with Python covers running it from a script.

Sampling a bulk OCR run: how many searchable PDFs to open and test

Open every file that the run flagged, every file that is unusually large, long or small, and a random sample of the rest drawn from each source. For a run of a few hundred files, a random sample of thirty to sixty is a workable start. Enlarge it as soon as one sampled file fails.

Why a sample, and what it can tell you

A sample cannot prove that every file is good. It can tell you whether failures are widespread. The arithmetic is simple enough to do yourself: if one file in ten were bad, the chance that thirty randomly chosen files all pass is 0.9 multiplied by itself thirty times, about 4 percent. So thirty clean files make a failure rate as high as one in ten unlikely. If one file in twenty were bad, thirty clean files would still happen about one time in five, and you would need closer to sixty to get the same comfort.

That is why the sample grows with what is at stake. For a set that will be searched to make a representation to a court, check far more, or check every file.

Choosing the files

Draw the random part with the spreadsheet: add a column of random numbers, sort by it, and take the first rows. Picking files "at random" by eye favors the ones with familiar names.

What to test in each file

Keep the per-file test short so that you do all of them. Confirm the page count equals the inventory's, then run the search checks in the guide to confirming a PDF is really searchable, and compare one page's picture with the original at high zoom. How many pages to test inside each file is covered under how many pages to test before trusting a searchable set.

One failure in the random sample means double the sample from that source. A second failure means every file from that source is checked or rerun. The post on why OCR output is full of errors helps you tell a bad scan from a bad run.

A run log for bulk OCR: file, pages, result and who checked it

A run log is the inventory with the outcome added: for each file, what was done, when, with which tool and settings, how many pages came out, whether it was sampled, and who checked it. It lets someone a year from now know which files' text came from recognition.

Add these columns to the inventory sheet instead of starting a new one, so that one row tells the whole story of a file:

Entries that deserve words, not a tick

• Failures. Write what the tool reported and what you did about it.
• Skipped scans. If a scan was skipped because it already had text, say whether that text was tested.
• Known weak pages. Handwritten pages, faxes and poor copies inside a file that otherwise passed.
• Files left out. Password-protected files, oversized files and anything awaiting a better copy.

Where the log lives

Save the log in the matter folder, at the top level, under a name that says what it is, such as OCR_run_log_2026-02.xlsx. Keep the summary figures in its first rows: files in the folder, files processed, files skipped, files failed, pages processed, sample size and sample failures. For the Pemberton folder that reads 640, 230, 410, 0, 6,900, 48 and 1.

Last, decide what happens to the two trees. Keep the original tree, read-only, until the retention rule for the matter says otherwise, and record in the log which tree is now the working one. If you used an online tool for the run, delete the uploaded documents from it once the exports are saved and checked. Schema Law's stated commitment on every plan is "Delete any document, at any time", set out in the security section.