eDiscovery OCR: Where It Fits in Document Review

eDiscovery OCR is the step that turns pictures of documents into text a computer can search. It belongs to processing, before review begins, and it applies to scanned paper, image-only PDFs, photographs and redacted pages. Without it those documents never match a search term, and a reviewer finds them only by reading every page.

That makes OCR a small step with large consequences. Most of what happens later in a matter, from search term negotiations to privilege screens, assumes every document has text behind it. The sections below show where the step sits, which files need it, and how much a small firm can do without a review platform.

Where does OCR sit in the e-discovery process?

OCR sits in the processing stage of e-discovery, after documents are collected and before anyone reviews them. Its job there is to give text to files that have none, so they enter the search index with everything else. It then returns twice more: when redacted pages are produced, and when an image-only production arrives.

The EDRM model defines nine phases: identification, preservation, collection, processing, review, production, presentation and disposition, with analysis running across all of them. It describes processing as "normalizing and converting ESI/documents for review and analysis". The EDRM Processing Glossary is more specific. Processing "encompasses the steps required to extract text and metadata from information items and to build a searchable index", and OCR is "the use of software to identify alphanumeric characters in static images (i.e., TIFF or PDF files) to facilitate text extraction and electronic search".

For a single scanned letter, the path through a matter looks like this:

1. Collection. The letter comes out of a file cabinet and through a scanner. It is now a picture.
2. Processing. OCR reads the picture and writes a text file. The index now knows the letter mentions the plaintiff.
3. Review. A search for the plaintiff's name returns the letter. A reviewer codes it responsive.
4. Production. The letter is stamped with a Bates number. If part of it is redacted, text is made again from the redacted image.
5. Presentation. At a deposition someone needs the paragraph about the delivery date and finds it by searching.

Take away step 2 and steps 3 and 5 fail without any warning. The letter is still in the database. It simply never appears in a result.

Which documents in a collection need OCR?

A document needs OCR when its content is a picture and no text can be pulled from the file itself. In practice that means scanned paper, faxes, image-only PDFs, photographs and screenshots, pictures attached to emails, and anything redacted. Emails, word-processing files, spreadsheets and PDFs saved from software already contain their text.

Three cases deserve attention because they slip through.

Mixed files. A PDF with a typed cover letter and forty scanned pages behind it passes a quick "does this file have text?" test on page one. Processing tools that OCR only files with no text at all will skip it. Check a sample of long PDFs past their first page. The post on why you can't copy text from a PDF gives the tests.

Images inside other files. A photo of a signed contract pasted into an email, or a scanned exhibit embedded in a presentation, is a picture within a file that otherwise has text. The surrounding words are indexed and the picture's words are not.

Handwriting. Notes, annotated drafts and forms filled in by hand may yield partial text or none. The post on OCR for handwritten notes sets out what to expect. Plan for a person to look at these whatever the software reports.

Some files should be left alone. A photograph of a warehouse or a diagram with no words gains nothing from OCR. Mark those for review by eye and move on.

In electronic discovery, recognized text is what review, a privilege screen, and a later production of electronically stored information all share. Sample a letter and a contract at the start, the middle, and the end before coding begins. A page with no words, such as a site photograph, stays an image you review by eye. Write on the processing sheet which files you recognized and which you left as images.

How does OCR quality affect search terms and review?

A search term finds a document only when the document's text contains that term, spelled the way you typed it. If OCR read "Harlow" as "Har1ow", a search for Harlow does not return the page. Nobody learns of the miss, because a document that is not returned is a document nobody opens.

This is the main risk of poor OCR in a review. Errors do not show up as wrong answers. They show up as missing ones, and they concentrate in the places a case cares about:

• Names. People and company names are not dictionary words, so recognition has nothing to correct them against.
• Numbers. Account numbers, invoice numbers, dates and amounts change meaning with one wrong digit.
• Short terms. A three-letter project code has no spare letters. One error and it is a different string.
• Banners and footers. Small print such as "Privileged and Confidential" is often the faintest text on a page. A privilege screen that searches for it will miss the pages where it was misread.

Search term hit counts inherit the same weakness. If the parties negotiate terms from a hit report, and a fifth of the collection is scanned paper with rough text, the report understates what those terms would reach in a clean set.

You can reduce the exposure without perfect OCR.

1. Measure before you search. Sort image-based documents by characters of text per page. A ten-page document with forty characters of text failed recognition, whatever its status says.
2. Use looser matching on scanned material. The Sedona Conference Glossary defines fuzzy search as one that lets characters in a term be replaced, "so that a broader range of data hits will be returned", with the example that a search for "fell" could return "tell", "fall" or "felt". Wildcards do similar work for names.
3. Sample what the terms did not hit. Pull a random set of scanned documents outside the search results and read them. If responsive documents turn up, the text is the first suspect.
4. Route the worst documents to people. Low-text pages, handwriting and bad faxes get eyes-on review instead of a search.

Any tool that groups, ranks or compares documents by their words depends on the same text, so the effect reaches beyond keyword search. For the causes of bad recognition and how to judge a page, see why OCR output is full of errors.

Extracted text versus OCR text

Extracted text is copied from characters already stored in a file. OCR text is a reading of a picture. The first is exact, because the software is reporting what the file says. The second is an estimate, however good, because the software is reporting what the page appears to say.

The EDRM Production Standards draw the line this way. Each searchable native file "has an extracted text file in .txt format", and each "non-searchable file containing text has a multipage OCR text file". Redacted files get OCR text as well.

Two practical points follow.

Redaction switches a document from one column to the other. An email has perfect extracted text until you redact a paragraph. From then on, the extracted text is a liability, since it still contains the hidden words. The produced version must carry text made from the redacted image.

Know which kind you are searching. When a production arrives with text files, the load file may say nothing about how each one was made. A document that looks like a scan almost certainly has OCR text, and its misses will cluster in names, numbers and small print. The data file's text path column, described in the post on the Concordance load file format, tells you where each text file is, not how good it is.

OCR for incoming versus outgoing productions

On an incoming production, OCR is something you do for yourself, to search what the other side sent. On an outgoing production, OCR text is something you may have to deliver, and what you deliver has to match the pages as produced. The first tolerates rough text. The second needs more care.

Incoming. Productions of paper often arrive as page images with poor text or none. Keep the delivery untouched and run OCR on a working copy, so you can always show what you received. The steps, and the question of whether you could have required a searchable form to begin with, are covered in the post on making a document production searchable.

Outgoing. When you produce scanned paper, check what the requests, any ESI protocol and your court's rules say about text. Agencies can be exacting. The SEC's Data Delivery Standards ask for "searchable document-level text files" with imaged productions, and require that a PDF production contain "embedded text that includes all discernible words within the document". Whether your matter demands anything similar depends on the parties' agreement and the jurisdiction.

Two rules keep outgoing text safe:

• Make the text from the final images, after redaction and stamping, never from an earlier version.
• Open a sample of the text files before delivery. A file that contains a redacted name, or text from the wrong document, is a problem you want to find yourself.

What a small firm needs without a review platform

A small firm with a few thousand pages can work without a review platform if every document is a searchable PDF in an orderly folder. You need three things: OCR that produces searchable PDFs and text, file names that preserve order, and a spreadsheet for whatever a platform would otherwise track.

A light setup looks like this:

• Searchable PDFs, one per document, named by Bates number or date. A PDF reader with a search-a-folder feature can search all of them at once.
• Plain text copies of the same documents, for comparing drafts and for search tools that read text files faster than PDFs.
• A hit list in a spreadsheet. For a document with no tables, Schema Law's CSV export lists each line of text with its page number. Filter that column in Excel for a term and you get every hit with a page reference to check.
• An index sheet with one row per document: Bates range, date, author, a one-line description, and columns for responsive, privileged and hot.

Schema Law covers the first three items. You upload a PDF, PNG or JPEG of up to 20 MB in the browser, it reads the pages into text and tables, and you export searchable PDF, plain text, CSV or other formats. You can choose several files at once, and they are read one after another. Each account belongs to one person, so a team does not work from one common set of documents. Its stated commitments, including that documents are never used to train an AI model and stay inside your own account, are set out under security commitments on the home page. It is a converter and not a review platform. It has no coding panel, no privilege log and no connection to any review tool, and it does not produce load files on any plan. The pricing page lists what each plan includes.

Know what the light setup gives up. A folder and a spreadsheet do not remove duplicates, group email threads, record who reviewed what, or stop two people coding the same document differently. Move to a platform when any of these is true:

• The collection is mostly email with attachments.
• More than two people are reviewing at once.
• You must produce with load files and metadata fields.
• The page count has passed what one person can keep track of in a spreadsheet.

Until then, a well-named folder of searchable PDFs is a legitimate litigation support setup. For larger sets, the post on batch OCR for discovery documents explains how to keep order across many uploads.