OCR Before Uploading to a Review Platform: Is It Needed?

You usually do not need to run OCR before uploading scans to a hosted review platform, because the platforms that publish their intake steps say they recognize text in image files and image-only PDFs themselves. Converting first still pays when you need the text outside the platform, or when its rules would skip your pages.

The honest answer depends on which platform you use and what kind of upload you make. This post reads the public help pages of three hosted platforms, Everlaw, Logikcull and DISCO, and reports what each says. Vendors change their products, so open the linked pages yourself before a deadline depends on them. Schema Law is a converter and connects to none of these platforms.

Do hosted review platforms OCR your uploads for you?

Yes, according to their own documentation. Everlaw, Logikcull and DISCO each describe OCR as an automatic part of taking in files. Each also attaches conditions: which file types qualify, how little existing text a page must have, and which kind of upload you chose.

Everlaw's article on uploading native data to Everlaw puts it in one sentence: "OCR is automatically run on all image files (TIFFs, JPGs, PNGs, etc.), inlined images in emails, and PDF pages with fewer than 50 embedded non-whitespace characters."

Logikcull's page on OCR, DTR and native text layers describes a check followed by a fallback: "When you upload a document, Logikcull will check if there is existing text metadata and use that to drive text searches. If there is no existing text, the platform will use Optical Character Recognition (OCR) to extract text from the document."

DISCO's article on understanding optical character recognition opens with a definition that places the step: "OCR is the process of extracting text from images during ingest."

So a folder of scanned PDFs dropped into any of the three should come out with text. That is what processing is for, and the post on where OCR sits in the e-discovery process explains the stage.

Two limits apply to that "yes". First, it covers hosted platforms with a plain upload. A load file import is different, because the load file carries the text and the platform takes what it is given. The post on OCR text for a Relativity load file covers that route. Second, "the platform ran OCR" and "the text is good" are separate facts. None of the vendor pages promises the second.

When is pre-upload OCR still worth doing?

Pre-upload OCR is worth doing when you need the text somewhere the platform is not, when the platform's intake rules would pass over your pages, or when you want to see the quality of the text before you pay to host the set. For a routine upload of clean scans, it is extra work.

Cases for converting first

• You have not chosen a platform. A banker's box arrives on Monday and the platform decision is two weeks off. Searchable PDFs let you start reading today.
• Most of the set will never be hosted. If you expect to load only the responsive tenth, you need text to find that tenth.
• You need a deliverable. A client, an expert or co-counsel without a platform login needs a searchable PDF or a Word file, not a link.
• A page already carries a little text. Everlaw's article on reprocessing documents in Everlaw says "PDF pages with more than 50 characters of embedded text are not OCRed upon upload." A scanned page whose only text layer is a typed fax header or an electronic stamp can clear a threshold like that while the body stays a picture.
• The pages are handwritten. Everlaw's native upload article says "the OCR tool used during upload is not optimized for handwriting" and points to a separate reprocessing option. General OCR struggles with handwriting everywhere, so plan for a person to read those pages.
• You want to judge the text yourself. Reading the output for ten representative pages tells you whether search will be trustworthy on the rest.

Cases against

• The platform may redo the work. Depending on the settings, a platform can replace the text you supplied with its own. The section on whether a platform keeps or replaces an existing text layer has the details.
• Two text versions invite confusion. If your searchable PDF and the platform's text disagree about a name, which one did the search use?
• File size. A searchable PDF is larger than the scan it came from, and some upload routes cap the size of a single file.

A fair rule for a small team: convert first when the text has a job to do before or outside the platform. Otherwise upload the scans as they are and spend your time checking what the platform produced.

Decide where the text has to exist before anyone codes. If the privilege review happens inside the platform, sample the platform's text after upload. If you must search the electronically stored information on a laptop first, run recognition first and keep that text file with the PDF. Write on the job sheet which text the review team is supposed to use.

What hosted review platforms document about scanned uploads

Each vendor's help pages describe when OCR runs, what triggers it, and what it skips. The table below quotes or closely paraphrases those pages and nothing else. It is a reading of documentation as published, not a test of any product, and it makes no claim about how well any of them reads a page.

Details worth knowing

Everlaw. A set of already-produced PDFs can go in through a different door. The article on uploading produced PDFs without a load file says that for PDFs with no embedded text, OCR is applied on upload to generate a text file, but "Everlaw does not generate a PDF with embedded text from these documents", and "hit highlights and other text-based tools in the review window do not work on the image view of these documents" until someone with the right permissions reprocesses them. That route also reads each document's Bates number from its file name.

Logikcull. Its list of automated steps during the upload process says documents "have OCR or text extraction applied" during processing, and notes that "as of October 2022, all PDFs uploaded will be processed through Logikcull's Deep Text Recognition (DTR)." The text layers page describes DTR as extracting text "from embedded images within supported file types". The same page says automatic OCR is attempted in English.

DISCO. The OCR article explains that recognition works together with language identification, and that "OCR is performed on all images on all pages of the entire document in the identified language." It lists the two exclusions shown in the table.

If your platform is not one of these three, ask its support team the same four questions the table's rows ask.

Will a review platform keep or replace an existing text layer?

It depends on the platform and the setting. Everlaw and Logikcull both document that existing text is used by default, and each describes an OCR run that replaces it. DISCO's OCR article does not address the question. Know the answer before you upload searchable PDFs you made yourself.

This matters in both directions. If you supplied careful text, you do not want it silently swapped. If the PDF came with a bad text layer from a copier, you want it swapped.

Everlaw. The reprocessing article says PDF pages with more than 50 characters of embedded text are not OCRed on upload. It then describes two forced options. Of the default it says: "Forcing OCR with the default option will not overwrite any text embedded in the PDF." Of the other, called Flatten PDFs: "Everlaw removes the embedded text layer from the PDF, then OCRs the PDF and replaces the embedded text with the OCR results." The article recommends that second option only for PDFs whose embedded text is invalid.

Logikcull. The text layers page says that for drag-and-drop and cloud uploads the platform "will use the existing text metadata for documents that arrive with a text layer". When its OCR does run, the page says the aim is to "replace any existing/provided text already in the text view with a newly-generated text file based on optical character recognition of the image." Where a database upload comes with text files for the imaged documents, the page recommends "utilizing the text files that have been provided and bypassing the use of our OCR engine." It also warns that documents "can be ingested with one, both, neither, or incomplete versions of text."

DISCO. The article says what is recognized "is then placed in a PDF". It does not say what happens to a text layer that was already there. Ask DISCO's support before you assume either outcome.

The practical reading: on Everlaw and Logikcull, by their own documentation, a searchable PDF you prepared is searched on your text unless an OCR run replaces it. That makes your OCR the thing reviewers depend on, so check it as carefully as you would check the platform's. The difference between text copied from a file and text read from an image is set out in the section on extracted text versus OCR text.

Preparing a folder of scans for a review platform upload

Prepare the folder so that each file is one document, each name is unique and meaningful, and the platform's stated limits are met. Then decide once, for the whole set, whether the files go up as plain scans or as searchable PDFs. Mixing the two makes later checking harder.

1. Read the platform's upload page. Limits differ. Everlaw's page for produced PDFs, for example, says all files must be PDFs, none may be password-protected, and folders cannot be zipped. Logikcull's production upload route asks for a single zip. Do not guess.
2. Split by document. One PDF per letter, contract or report. A 600-page PDF of a whole box becomes one unreviewable record.
3. Name the files. Use the Bates number if the pages are stamped, or a date and short title if not. Avoid spaces and punctuation other than hyphens and underscores.
4. Keep an untouched copy. Whatever you upload, the scans as received stay in a separate folder.
5. Remove passwords and junk. Take out thumbnail files, shortcuts and anything encrypted.
6. Convert, if you decided to. In Schema Law you upload each PDF, PNG or JPEG of up to 20 MB and export a searchable PDF, which is your original file with a hidden text layer. On any plan you can choose several files at once, and they are read one after another. The how it works section shows the steps.
7. Write an inventory. A spreadsheet with file name, page count and whether the file was converted before upload.
8. Upload a sample first. Twenty documents, including the worst-looking ones.

The inventory earns its keep when a reviewer asks why one document has no highlights or odd text. Without it, nobody can say whether the text came from your conversion or from the platform's.

A worked example. Ortega Supply sends its lawyers 140 scanned purchase orders and a folder of 30 handwritten delivery notes. The firm's platform skips pages that already have text. The purchase orders have a typed fax banner on every page, so the paralegal converts those first and uploads searchable PDFs. The delivery notes go up as plain scans and are assigned to a person to read, with a tag saying search cannot be relied on for them.

Spot-checking platform search hits against the scanned pages

Check the platform's text by searching for words you can see on the page images. Pick documents, read a name or number off the image, search for it, and count how often the document comes back. A miss means the text is wrong, absent or attached to another document.

A sample of 25 documents is enough to show a pattern. Choose them on purpose, not at random: five clean typed pages, five faxes, five with stamps or handwriting, five with tables, five of the longest.

For each document:

1. Open the image and write down one proper name, one number of six or more digits, and one ordinary phrase from the middle of a page.
2. Search for each. Record hit or miss.
3. Open the platform's text view and compare the first and last lines with the first and last lines of the image. This catches truncated text.
4. Note whether highlighting works on the image. If it does not, the document may have text but no layer on the image.

Vendors describe their own aids for this. Logikcull's text layers page suggests filtering on the "OCRed" auto tag and using fuzzy search "to take into account any mis-read characters". Everlaw's reprocessing article describes a label that marks documents with no embedded text layer.

Record the sample and its results in the matter file. If search terms are later negotiated from hit counts, you will want to show that you tested whether scanned documents could be hit at all. The reasons recognition fails on particular pages are covered in the post on why OCR output is full of errors, and the pricing page lists page limits if you decide to re-run a group yourself.