Make PDF OCR Readable for a Portal That Rejected It
By Schema LawPublished Updated
To make a PDF OCR readable for a portal or a person that rejected it, give the file a text layer. They want words a computer can pull out of the pages, and your scan holds only pictures of words. Run OCR on a copy, save a searchable PDF, confirm text copies out of every page, and send that file.
A rejection is irritating because the file looks fine to you. It opens, the pages are legible, and nothing seems wrong. The receiving side is not looking at the pages, though. It is asking the file for its text and getting none back.
Search the repaired file the way the receiving system will read it. Look for the party names, the docket number, and the pleading title, then for an exhibit and an affidavit if those pages are in the upload. Open each hit and compare it with the page image. A motion that shows as a clear picture and has no matching text will fail that same check again.
What does a request for an OCR readable PDF actually ask for?
A request for an OCR readable PDF asks for a PDF with a text layer: real characters stored in the file, which OCR produces from a scan. The requester wants to search the document, copy from it, or pass it to software that works on text. The phrase describes the result they need, and OCR is how you get there.
The wording comes in several forms, and it may not tell you what the system checks. Read the request for what the recipient intends to do with the file.
| What the notice says | What it is likely to mean | What to confirm if unsure |
|---|---|---|
| "File is not OCR readable" | No text could be extracted from the pages | Whether every page needs text or only the file as a whole |
| "Please submit a text-searchable PDF" | Same request, in the more formal wording | Nothing; proceed |
| "Document must be machine readable" | Text a program can extract, possibly more | Whether they mean searchable text or a structured or tagged file |
| "Upload failed: unreadable document" | Either no text, or the file would not open at all | Ask for the error detail; the word covers both |
| "We cannot process image files" | They received pictures and need characters | Whether a searchable PDF satisfies them or they want the original electronic file |
| "Please send a clearer copy" | A person could not read the pages | This is about legibility, and OCR will not fix it; rescan |
The last two rows show why the question is worth asking. A person who writes "unreadable" may mean the pages are too faint for human eyes, and no text layer will help with that. The different senses of the word are separated in the post on making a PDF readable, under what it means for a PDF to be readable.
When the requester has published file requirements, those govern. A one-line question to a help desk, "Does the file need selectable text on every page?", costs less than a second rejection.
Why do upload portals reject a scanned PDF as unreadable?
An upload portal rejects a scanned PDF as unreadable when it asks the file for text and receives nothing. A scan is a stack of pictures. Software that extracts characters gets an empty result from each page, and a portal built to index, route or analyze text has nothing to work with.
Portals differ, and each one's own instructions are the only reliable account of what it checks. What follows is what a receiving program is able to test on any PDF, so you know the possibilities when the notice is vague.
Checks a receiving program can run
- Does text come out? The program runs a text extraction on the file. An image-only page returns no characters.
- Does text come out of every page? A stricter check counts pages with no characters. A file with a typed cover sheet and scanned attachments passes the first test and fails this one.
- Is the text usable? A program can go further and look for recognizable words. A page whose stored text is symbols or scrambled letters can fail here although it technically has text.
- Can the file be opened at all? Password protection, damage in transit or an unexpected file type stops everything before text is even considered.
- Is the file within limits? Size, page count and page dimensions can all be capped.
Why the receiving side cares
The reason varies with the system. A search function needs words to index. A claims or intake system may pull names, dates and reference numbers from the text to route the document. A reviewer may need to copy passages. A system with accessibility obligations may need text that assistive software can read. In each case a picture of a page is a dead end for the software, however clear it looks on your screen.
Rejection by a person
Sometimes no program is involved. A clerk, an adjuster or opposing counsel opens the file, tries to search it, and sends it back. The fix is the same. The difference is that a person can tell you exactly what they tried, so ask.
Court e-filing systems have their own published standards, which differ from court to court. This post does not describe them. The post on searchable PDFs for court filing covers what to look for in your court's rules and procedures.
Making a rejected PDF OCR readable and sending it again
Making a rejected PDF OCR readable takes six steps: read the notice, confirm the file lacks text, run OCR on a copy, save a searchable PDF, test it, and resubmit with a record of both attempts. Converting a scan to a readable PDF is the short part. The checks around it prevent a second rejection.
- Read the rejection and the portal's file requirements together. Note every requirement, not only the one you failed: text, size, file name pattern, security, file type.
- Confirm the diagnosis. Open the rejected file and try to select a word on a page in the middle. If nothing selects, the page is a picture and OCR is the fix. If words do select, the cause lies elsewhere, and the post on working out why a PDF is not searchable walks through the other causes.
- Copy the file. Keep the version you first submitted. You may need to show what was sent and when.
- Run OCR and save a searchable PDF. Use whatever tool you have that writes the recognized text into the PDF; the guide on how to make a scanned PDF searchable has the full procedure. In Schema Law, upload the file and choose the Searchable PDF export. Uploads are PDF, PNG or JPEG up to 20 MB, and the page allowance for one document depends on the plan, as the pricing page sets out.
- Test the new file. Extract its text the way a receiving program would, and confirm that every page contributed real words.
- Resubmit and keep the trail. Save the rejection notice, the new file and the acceptance confirmation together in the matter folder.
A worked example
A paralegal at a fictional firm uploads 46 pages of treatment records to the document portal of Northgate Mutual, a fictional insurer, in support of a claim for a client named Elise Varga. The portal replies: "Document rejected: not OCR readable."
She opens the file and drags across a line on page 20. A blue rectangle appears and no words are selected. The file came from the provider's fax server and is pictures throughout. She copies it, runs OCR, and saves Varga_treatment_records_searchable.pdf. She pastes the text of pages 1, 20 and 46 into a text editor and reads sentences on all three. The portal's instructions cap uploads at a size her new file is under. She uploads it, the portal accepts it, and she files the rejection email, both PDFs and the confirmation number under the same date.
If a deadline is running
A rejected upload may or may not count as received on the day you first tried. That depends on the rules or terms that govern the submission. Note the time of the first attempt, keep the notice, and raise it with the responsible lawyer the same day so the question is not discovered later.
Scannable, readable, searchable: is it one request in three words?
Scannable, readable and searchable are, in a rejection notice, three words for one request: a PDF with text a computer can find. People reach for whichever word they know. A few neighboring terms do ask for something different, so check before you treat every phrase as a synonym.
| Term in the request | Same as "OCR readable"? | Note |
|---|---|---|
| Searchable, text-searchable | Yes | The standard wording |
| OCR'd, OCR readable, OCR compliant | Yes | Names the method and means the result |
| Scannable | Probably | In this sense it means a computer can scan through the file for words. It has nothing to do with paper being fit for a scanner |
| Readable, machine readable | Likely, but confirm | "Machine readable" can also mean structured data |
| Text-based, "not an image" | Yes | Describes the same thing from the other side |
| Selectable, copyable | Yes | A person describing the test they ran |
| Accessible, tagged | No | Asks for structure a screen reader can follow, which a text layer alone does not supply |
| Native, original format | No | Asks for the file the document was created in, such as the Word document, and not a scan of any kind |
| PDF/A | No | Asks for an archival variant of PDF, which is a separate property from having text |
So if you came here asking how to make a PDF scannable, the answer is the same procedure as for OCR readable. Give the file a text layer.
The three "No" rows are where a second rejection comes from. A searchable scan sent in answer to a request for a native file is still the wrong thing. If the notice uses one of those terms, ask what is required, and see the posts on what PDF/A is and on native and scanned PDFs for the vocabulary.
When the same sender uses two different words
A portal's upload page may say "searchable" while its error message says "readable" and its help article says "OCR". Treat the published requirements page as the authority, the error message as a symptom, and a reply from the help desk as the tie-breaker.
Testing a PDF the way the receiving system will read it
Test the PDF by pulling its text out the way a program would, instead of looking at the pages the way a person does. Export or copy the text of the whole file, then check that every page contributed real words. Run the test on the exact file you will upload, after any renaming or compression.
The pre-send check
- Close and reopen the file from where it is saved. You want to test what is on disk, not what your OCR program is holding in memory.
- Extract everything. Use Select All and Copy, or your program's option to save the document as plain text, and put the result in a text editor.
- Look at the amount. Forty-six pages of records should yield many screens of text. A few lines means only a few pages have a layer.
- Find the gaps. Scroll the extracted text and compare page breaks or page headers against the page count. Then spot-check in the PDF itself: go to the first page, the last page and any page that looks different from its neighbors, and select a word on each.
- Read a paragraph. Pick one at random from the extracted text. It should read as language. Strings of symbols mean the layer exists and is useless.
- Check the file properties. Look at the security tab for any restriction and at the file size against the portal's limit.
- Open it in a second program. A file that yields text in two unrelated PDF programs is unlikely to puzzle a third.
| Result | Meaning | Action |
|---|---|---|
| Text from every page, reads as language | Ready | Upload |
| Text from some pages only | Mixed file | Run OCR on the picture pages, or on the whole file if your tool handles mixed input |
| Text from every page, nonsense on some | Poor recognition or a damaged layer | Redo those pages from the best available scan |
| No text at all | The saved file is not the OCR output | Find the right file; you may be testing the original |
| Text present, copying blocked | A security setting | If you set it, save a copy without it; if someone else did, ask them for an unrestricted file |
Looking directly at a file's stored text is covered at more length in the post on seeing the text layer in a PDF. For a batch of files going to one portal, the post on checking whether a PDF is searchable has a method for sets.
No test on your desk reproduces the portal exactly. You are removing the known causes. If the portal publishes a validation tool or a test upload area, use it.
When an OCR readable PDF is still rejected: fonts, security and size
When a PDF with a sound text layer is rejected again, the ground has moved from text to something else the portal checks: security settings, fonts, file size, file type or naming. Reread the notice, since the second message may not match the first, and compare the file against each published requirement in turn.
| Ground | How to recognize it | What to do |
|---|---|---|
| Security or encryption | The properties show a password or restrictions on copying or printing | If you applied the protection, save a copy without it. If someone else did, ask them for an unrestricted file |
| Fonts not embedded | Applies to typed pages in the file, not to scanned ones; the properties list fonts without "embedded" beside them | Re-create the typed pages from their source document with fonts embedded |
| File too large | The size exceeds the stated cap | Shrink or split, then test for text again afterwards |
| Wrong PDF variant | The requirements name PDF/A or a version number | Convert with a tool that produces that variant, and validate it |
| File name | The requirements limit length or characters | Rename to the stated pattern |
| Attachments, forms or scripts inside the PDF | The file is a portfolio, has fillable fields or carries embedded files | Send plain pages; ask the portal how it wants attachments |
| Unusual page size or rotation | Oversized or sideways pages | Check the requirements for page dimensions and rotate pages upright |
| Text present but garbled | Pasted text is symbols | Replace the layer, as the post on converting a PDF to readable text explains |
Three of these need care.
Security. A restriction placed by another party may be there for a reason, such as a protective order or a licence. Do not look for a way around it. Ask the sender. The post on protected PDFs explains the kinds of protection a file can carry.
Size. OCR itself adds little to a file, but a scan that was close to the cap may now be over it. Shrinking is where text layers get lost, because some size-reduction methods rebuild pages as pictures. Always rerun the text test on the reduced file. The post on searchable PDF file size covers reducing a file while keeping its text.
Fonts. A scanned page has no fonts to embed in its picture. If a portal complains about fonts, look at the typed pages in your file, such as a cover letter or an index you added, and at how the text layer was written.
Asking for help usefully
If the file passes every published requirement and still bounces, write to the portal's support with facts they can act on:
- The exact text of the rejection and the time of each attempt.
- The file's size, page count and PDF version from its properties.
- A statement that text extracts from every page, and how you tested.
- A request for the specific check that failed.
A message like that gives support something to look up in a log. "It won't upload" does not. Meanwhile, ask whether there is another accepted way to deliver the document, and keep the responsible lawyer informed if a deadline depends on it.
If you need to rebuild the file from the scan, Schema Law's how it works section shows the upload and export steps. Recognition there is strongest on clean print and weaker on faint faxes and handwriting, and nothing marks a passage as uncertain, so run the pre-send check on whatever you export.