My scanned PDF says it's searchable, but search finds nothing

Why a scanned PDF is still not searchable after OCR

Searchable is a property of whichever index read the file, not of the file. Five faults produce that symptom, in three families: the file has no usable text layer, the tool doing the searching never re-read it after OCR ran, or the words are in there and they are wrong. One test tells you which.

Three separate things get collapsed into the word searchable. A text layer can exist. A text layer can be readable. And the thing doing the searching can actually have read it. Those fail independently of each other. A PDF can pass the first two and still be invisible to Spotlight, and it can fail the third on a file that is in perfect shape.

With one file this is ten minutes of annoyance. With eight hundred scanned pages it is a decision: re-run OCR across the whole corpus, or rebuild an index, or go back to the scanner. Those are three different afternoons, and the test below tells you which one you are having.

The 30-second test that tells the file from the index

Adobe’s own hub page gives one test: drag-select across the page, and “if nothing is selected, there is no text, and the file isn’t searchable”. That is true in one direction only. Selecting text proves a text layer exists under your cursor. It does not prove the layer covers the rest of the document, and it does not prove the characters map back to the letters you would type. Both of those faults select perfectly well and stay unsearchable.

Run these five in order and stop at the first one that gives you an answer. Steps 1 to 3 are the thirty seconds; 4 and 5 want a terminal.

1. Search a word from the middle of the document, in a second reader.Not page one, which is the page most likely to pass for the wrong reason. Pick something distinctive from the middle of the file, open it in a PDF reader you did not run the OCR in, and search. This tests the file rather than an index: a reader’s Find command reads the file it has open, while Spotlight and Windows Search answer from a stored index, and so does any document app that keeps one. Readers can differ, and one 2013 Super User answer reports a PDF that found nothing in macOS Preview and searched fine in Adobe Reader. Done looks like: found in the second reader means the file carries text on that page, which points at Cause 4; confirm with step 3 before you act on it. Not found means keep going.
2. Select all, copy, paste into a plain text editor.TextEdit, Notepad, anything with no formatting. What lands in that window is what any text extractor has to work with. Evernote’s own help article uses this test and says that if “the pasted content appears garbled or unreadable, this suggests that the PDF contains invisible text”. Done looks like: nothing pastes, which is Cause 1. Boxes, question marks or scrambled characters paste, which is Cause 3. Readable text pastes but not the word you searched, which is Cause 5.
3. Repeat the paste on three pages spread through the file. Page one, a page in the middle, the last page. This is the only step that tells you whether the fault is the file or only part of the file. Hybrid files are real: Litera’s support article on them describes PDFs that combine image-based pages and text-based pages, and notes that text pasting into Word is evidence of a text layer in at least a portion of the file. Done looks like: you know whether the fault covers every page or only some. Only some is Cause 2.
4. Dump the text layer at a terminal. Run pdftotext file.pdf - | head (poppler-utils; on a Mac, brew install poppler). The man page says what the tool does, “Pdftotext converts Portable Document Format (PDF) files to plain text”, and what the dash is for: “If text-file is ‘-’, the text is sent to stdout.” So the text lands on your screen instead of in a file. Done looks like: you see the text layer the way a machine sees it, with no reader rendering in between. Nothing printed is Cause 1, confirmed.
5. Check the font map at a terminal. Run pdffonts file.pdf (poppler-utils) and read the uni column. Per the man page that column says yes “if there is an explicit ‘ToUnicode’ map in the PDF file”, with the caveat, also in the man page, that its absence “doesn’t necessarily mean that the text can’t be converted to Unicode”. Done looks like: a file that pastes as boxes and shows no in that column usually has a broken character map, which makes Cause 3 the likely explanation.

Running the test over 800 files instead of one

Those five steps are a per-file ritual, and nobody is doing them eight hundred times. Once poppler-utils is installed, a shell loop around pdftotext turns the same check into one pass over a folder. It prints the size of each file’s text layer with the smallest first, so the files with nothing in them float to the top:

for f in *.pdf; do printf '%s %s\n' "$(pdftotext "$f" - | wc -c | tr -d ' ')" "$f"; done | sort -n | head -40

The bands are rules of thumb, not thresholds. A file reporting a few dozen characters has no usable text layer. A few hundred characters across a twenty-page document means one page came through and the rest did not, or hidden scanner text spread thinly over every page, and either way that is Cause 2. Anything in the thousands has text, and if search still misses those files you are looking at Cause 4 or Cause 5, and no amount of re-OCR will help.

One thing to know before you read the numbers: pdftotext emits a form feed for every page, so an image-only file never reports zero. We built a four-page image-only PDF and ran the loop over it, and it came back at four bytes, which turned out to be four form feeds and nothing else. A twenty-page scan with no text layer reports around twenty. Sort the corpus once this way and the rest of this page applies to a list rather than to a file.

Cause 1: there is no text layer at all

A scanned page is a picture of words. OCR does not change the picture. It draws a second, invisible copy of the words on top of it, positioned where each word sits in the image, so the page still looks like a scan and a copy command now returns text. Everything downstream, search included, reads that invisible copy and never looks at the picture. If the copy was never written, the file is an image and search has nothing to match against.

One public count gives a sense of scale. CCpdf, a set of 967 PDFs pulled off the web and hand-annotated for ICDAR 2023, classed 18% as scanned and another 33% as needing OCR, a label the paper never defines in prose, so read the second group loosely. Web PDFs are not home scans either, so take the direction and not the number.

The tell inside a document app is a per-document word count. A user reported on the DEVONthink forum in August 2026 that PDFs which had been through ABBYY OCR were landing at zero words and staying unsearchable with no warning, which the reporter blamed on the text extractor rather than an import setting. The vendor has not confirmed the diagnosis. The zero is still the number worth watching.

One more reason a text layer never got written: the file was locked. Adobe lists “Encrypted or password-protected PDFs” among the things that stop OCR, because “security measures can block OCR access to text content”.

The case that catches people out is OCR that ran inside another app rather than on your own machine, because it does not follow that the file carries the result. Google’s own documentation illustrates the distinction well: Drive’s convert-to-text feature produces a separate Google Docs file, and Google says the file should be 2 MB or smaller. Google documents nothing about writing text back into the PDF itself, so do not assume a PDF you download from a service that searched it for you carries a text layer. Run the test on the downloaded file. After you move a notebook out of Evernote, run the test above on the exported file before assuming the scans came across searchable. The fix, when there is nothing in the file, is below: re-OCR from the page image.

Cause 2: OCR skipped the pages that already had a little text

Both of the common tools refuse to touch a page that already reports text: OCRmyPDF by default, Acrobat with an error. They are right to. Re-reading a born-digital page usually makes it worse, because a perfect text layer gets replaced by a guess. The trigger is a single page, and the refusal is the default, which is why one odd page can turn the whole job into a no-op.

OCRmyPDF(17.x) documents it flatly: “If a page in a PDF seems to have text, by default OCRmyPDF will exit without modifying the PDF.” Not skips the page. Exits.

Acrobat does the same thing with a visible error instead of a silent one. Adobe’s own help page on it is not currently fetchable, so treat this as user-reported: a 2017 post in Adobe’s community forum records the message on Acrobat XI as “Acrobat could not perform recognition (OCR) on this page because: This page contains renderable text.”

It takes very little text to trigger the refusal: a fax header line, a stamped page number, a Bates stamp from a lawyer, a born-digital cover sheet on the front of a scanned contract, or a signature block pasted in before the file was flattened.

And the source nobody expects, which Evernote publishes a help article about: the scanner. In Evernote’s words, “if you’re using a multifunction printer to scan documents to PDF ... it’s possible that the PDF contains hidden text added during scanning, which prevents it from being properly indexed.” Their remedy is to turn the printer’s own text recognition off and scan as “PDF (Image Only)”, then let the software that indexes the file do the reading. The article was created in January 2025 and updated in August 2026.

It inverts the usual advice. For a document you intend to index somewhere else, the scanner’s built-in text recognition is a liability rather than a feature, and turning it off is a setting change on the machine rather than a repair job on eight hundred files. The rest of the settings that decide this are in how to digitize paper documents. When the scanning is already done, the fix is below.

Cause 3: the text layer is there, and it is not the alphabet

A broken font map is the hardest of the five to spot, because everything looks right: the text selects and copies, and search still matches nothing. A 2025 thread in r/pdf puts it in one line, after running Acrobat’s OCR: “The text is selectable, but not searchable.”

The cause is the font’s character map. A PDF font stores shapes plus a table saying which Unicode character each shape stands for, and that table is the ToUnicode map. If it is missing, wrong, or the glyphs were re-ordered when the file was written, the page renders perfectly on screen and extracts as boxes, question marks, or the right letters in the wrong order. The accepted answer on a 2013 Super User thread lists the usual suspects: a file “may have a custom font encoding”, it “may render characters individually out of sequence”, or it “may have had characters flattened to paths”.

Two tells, both from the test above. The paste gives you boxes or nonsense, and pdffonts shows no in the uni column, remembering the man page’s caveat that a missing map does not by itself prove the text cannot be converted. OCRmyPDF names this exact situation in its docs as the reason force mode exists: “This is useful for redoing OCR, for fixing OCR text with a damaged character map (text is selectable but not searchable), and destroying redacted information.”

Re-OCR from the page image fixes all three file-side causes

Causes 1, 2 and 3 are one repair: throw away whatever text the file claims to have and read the page image again. The diagnosis still matters, because it tells you whether you are finished. Re-reading the image repairs those three and does nothing whatsoever for Causes 4 and 5.

The free route is OCRmyPDF 17.x, which needs Tesseract installed alongside it. The blunt version is force mode:

ocrmypdf --mode force in.pdf out.pdf

The docs spell out what that costs: “all pages will be rasterized to images, discarding any hidden OCR text, rasterizing any printable text, and flattening form fields.” On a hybrid file that is real damage, because the born-digital pages lose their perfect text and get an OCR guess in its place. A third mode exists, --mode redo, whose legacy alias is --redo-ocr(the docs note that “the legacy flags (--force-ocr, --skip-text, --redo-ocr) remain as silent aliases”), but the page we verified does not define what it does, so check the OCRmyPDF documentation before using it. Whichever mode you pick, run it on a copy.

In Acrobat, Adobe’s hub page gives the path: “Head to Tools and select Recognize Text”, then “Press PDF Output Style Searchable Image.” Acrobat also offers a second style, Searchable Image (Exact), which a University of Kansas Libraries guide describes as applying “OCR as an invisible layer over the top of the untouched image”, the one to pick when you want the scan left alone.

What no source we could verify documents is an Acrobat setting that overrides the renderable-text refusal. On a page Acrobat has already declined, the menu path above will decline it again. The only route anybody writes down is user-reported: a reply in that 2025 r/pdf thread ran Preflight, converted the fonts to outlines, and then ran Recognize Text, which leaves the page with nothing for Acrobat to object to. Treat that as a forum workaround rather than a supported feature, and keep the original file.

If you re-OCR eight hundred files and search still comes back empty, you never had a file problem. You needed a reindex, or a better scan. Those are the next two sections.

Cause 4: the file is fine and the search tool never read it

When the paste is clean and the word is right there in the pasted text, the PDF is not the problem. Something is keeping an index, and your file is either missing from it or sitting in it in a version from before OCR ran.

On macOS, force Spotlight to rebuild through the privacy list. Per Apple’s support article, published August 2026: open System Settings, go to Spotlight (Siri & Spotlight on older versions), open Search Privacy (Spotlight Privacy on older versions), add the folder or disk, then remove it again. Apple’s wording for what happens next is the whole point: “Spotlight now reindexes the contents of the disk or folder.”

On Windows, file contents reach the index through a component called an IFilter. Microsoft’s documentation says that “Microsoft Windows Search uses filters to extract the content of items for inclusion in a full-text index”, and that for each file type “each type works with only one filter”. If the PDF filter is missing, broken, or registered to a program you uninstalled last year, every PDF on that machine is a filename and nothing else.

Document apps keep their own index, and the good ones publish a tell. DEVONthink prints a word count per document, so you can see at a glance whether it holds any text at all; PDF+Text is the state you want. When one sits at zero words you still do not know which side failed, so reach for the instrument: run pdftotext on that same file. Text on your screen means the index is the fault. Silence means the file is.

In Acrobat, users report that Preferences, then Search, then Purge Cache Contents clears a stale search cache. Adobe publishes no documentation for it, so treat that one as user folklore rather than a documented fix.

Granite fails the same way. A document is searchable only once its processing finishes, and until then keyword search and plain-English search both skip it. A large scan is queued, not instant, and looking for it thirty seconds after upload is a Cause 4 problem you created yourself.

Cause 5: the words are there and they are wrong

OCR read the page and produced text. The text is not what is printed on the page. Search is working exactly as designed, and the word you typed genuinely is not in the file.

Scan quality decides this, and nothing downstream repairs it. Tesseract’s own guidance gives the number everyone quotes: “Tesseract works best on images which have a DPI of at least 300 dpi”, and it names crooked pages in the same breath, warning about a page that “is too skewed, which severely impacts the quality of the OCR”. The US federal rule for digitizing permanent modern textual records lands on the same figure: 36 CFR 1236.50, effective June 2023, requires image files at a minimum of 300 ppi sized to the source document, with a stated floor of 294 ppi (300 ppi minus two per cent) and a bit depth of 8 or 16. It is a reasonable floor to borrow for paperwork you intend to keep for thirty years.

Adobe’s page on OCR that does not recognize text adds the two settings people skip. Straighten the page: “Be sure your scan is straight. If the document is skewed when scanned, the characters can become unrecognizable.” Most scanner software has a deskew option, and it costs nothing to turn on before a batch. Then pick the format on the way in: “Save scanned documents in OCR-friendly formats such as TIFF or PNG rather than JPEG.” JPEG compression puts its artifacts exactly where letters have edges.

The language setting is its own sub-cause, and it is the one that produces text which looks almost right. Adobe’s instruction is a single line: “Ensure that the OCR software is set to the appropriate language for the scanned text.” Adobe does not say what goes wrong. The damage lands hardest on accented characters and the words holding them, which is enough to put a word beyond a search that spells it correctly.

The errors are not evenly spread, and that is the part that matters for search. The British Library measured OCR quality across its 19th-century newspaper archive and published the results in D-Lib in 2009: 83.6% of characters correct, 78% of words, and then the two numbers that sting, 68.4% of significant words and 63.4% of capitalised words. Those were 2009 engines reading newsprint, so do not carry the figures across to a 2026 scan of a bank statement. Carry the shape across instead. What OCR gets wrong most often is names and places, and names and places are what people type into a search box.

The other half of the miss is your query. A ligature whose font carries no map back to f and i; a soft hyphen at a line break; a curly quote where you typed a straight one. Each can leave a string that does not match what you type. Search for one distinctive word rather than a phrase, and prefer a word with no punctuation in it. Word splitting does the same damage from the other direction: a 2018 StackOverflow thread describes OCR breaking FOR EXAMPLE into FOR EX AMPLE, which leaves an index entry for ample and none for example.

No software recovers a bad scan after the fact. A faded thermal receipt, a fax of a fax, a photo taken at an angle in poor light. A better engine helps at the margin and cannot read ink that is not on the paper. If the original still exists, rescan it. If it does not, put the two or three things you will actually search for into the filename or a note beside it. Thermal receipts are the usual casualty, and organizing receipts is mostly a race against the paper fading. The same goes for the piles you work through when you go paperless at home: scan the faded things first.

What Granite does with a scanned PDF

Granite decides page by page whether to believe a PDF’s text layer, rather than once for the whole document. That is a direct response to Cause 2: one page carrying a fax header is not evidence about the other forty. A page gets read again when any of these is true, as the pipeline is tuned today:

• its embedded text is under 100 characters
• fewer than 85% of its characters are printable at all
• more than 20% of its tokens look like scanner junk, meaning words with digits jammed into the middle of them, like PL6FORD
• more than 10% of its characters are box or replacement glyphs
• it carries a full-page image of 3 megapixels or more, in which case the text layer is not trusted however long it is, or an image of half a megapixel or more on a page holding under 600 characters

The box rule has a story behind it. A subset font with no usable ToUnicode map, a pattern Granite keeps hitting in European institutional and lab PDFs, makes a text extractor emit a box for every glyph it cannot map. Those boxes are symbols, so they sail past a printable-character check and past a junk-token check, and the document takes the fast path with its text layer trusted. Handed a page of boxes, a vision model does not report boxes. Granite found out the hard way: a Polish lab result came back as “Jan Kowalski / ALAB”, none of which was on the page. The threshold exists so that page never reaches the model. There is a deliberate exception in it too. The rule counts the missing-glyph box and the replacement character, and specifically not the empty square, because that one is a real checkbox on real forms, and counting it would push perfectly readable intake forms and ballots through a needless re-read.

When a page does need reading, Gemini 3 Flash reads the page image at 200 DPI. A page too large to send in one piece is scaled down rather than failed. The text that comes back is stored against that page and indexed below the title and the fields Granite pulled out, so a phrase from page nine will find the document, just behind a match on its title or its amount. What Granite reads off each document and how it gets found again are both built on that page text being right.

Whether a PDF’s text layer can be trusted varies page to page inside the same file. That is why the decision is made per page rather than per document, and why there is no setting for it. It is also not a rare case. Granite’s count of the 1,426 PDFs that 50 people uploaded between 28 May and 15 September 2026 found that 864 of them, 61%, arrived with a text layer that failed at least one of those checks on at least one page. Those are the PDFs of people who chose a document vault, so the share says nothing about PDFs in general, and it counts a file that needed one page re-read the same as a file with no text at all.

What Granite does not solve

Of the five causes, Granite removes the first three inside its own vault and does nothing about the last two outside it. The specifics:

• A bad scan stays bad. Faded thermal paper, handwriting, a phone photo at 150 DPI in poor light. Reading it again with a better model does not invent ink.
• Granite cannot touch your other indexes.Spotlight, Windows Search, a NAS search box, your scanner’s own software. Cause 4 on your own Mac stays your job.
• Granite keeps its reading to itself, and never hands back a repaired PDF. The file you export is the file you uploaded. If you need a fixed PDF to use elsewhere, run OCRmyPDF or Acrobat over it yourself.
• There is no button that says read this again. Reprocessing a document re-files it using the text it already has.
• No engine is right about every character, Granite’s included. A keyword search can miss a document that a plain-English question finds, because the question does not depend on every character being correct.
• There are caps. 50 MB per upload (1 MB for plain text and Markdown), and 50 pages per document on Free, 200 on Paid.
• A big scan is queued, not instant, and it is not findable until the queue reaches it.
• Password-protected PDFs are unlocked on the web app and the iPhone app only, using the password you give. Email-in, Dropbox sync and Evernote import cannot unlock one.

Sources

Primary sources for the claims above, read on 2026-09-14: the poppler-utils man pages for pdftotext and pdffonts (Debian trixie); OCRmyPDF 17.x on OCR modes; Evernote’s help article on PDFs that will not index (created January 2025, updated August 2026); Apple on rebuilding the Spotlight index (published August 2026); Microsoft on Windows Search filters; Tesseract on improving OCR quality; 36 CFR 1236.50 (effective June 2023); the British Library’s newspaper OCR study in D-Lib (July 2009); CCpdf, Table 3 (ICDAR 2023); Google on converting PDF and photo files to text in Drive; and Adobe’s Acrobat hub pages on making a PDF searchable (quoted here both for its menu path and in order to disagree with its select-all test) and what to do when OCR does not recognize text; plus the University of Kansas Libraries guide to Acrobat OCR. User reports, cited as user reports rather than as documentation: r/pdf on selectable but not searchable text (2025), the Super User thread on custom font encodings and on Preview finding nothing (2013), the DEVONthink forum thread on zero-word PDFs (August 2026), the Adobe community post recording the renderable-text refusal (2017), Litera’s support article on hybrid PDFs, and a StackOverflow thread on OCR word splitting(2018). Granite’s own behavior is read from the pipeline source at commit e9bb2f98 on the same date; the 61% figure is a read-only count of the ocr_used flag on 15 September 2026, demo accounts excluded, no document contents read. Menus, prices and vendor defaults change; check the current version before relying on one here.