Is your PDF actually searchable?
Last reviewed: September 23, 2026 · Markdown version
Some PDFs are text. Some are photographs of text. They look identical on screen, and only one of them can be searched — which is why "search inside this PDF" sometimes finds nothing in a document you can plainly read with your own eyes.
Drop a PDF below and this page will tell you which kind you have.
The file never leaves your browser. Nothing is uploaded, no network request carries it anywhere, and nothing is stored — the check runs on your own machine, in this page. Close the tab and it is gone.
What this page actually looked at
This is a structural check: it looks for the text-drawing instructions inside the file. It does not read your document, does not judge what it says, and cannot tell you whether the text layer is accurate — only whether one is there.
Why the character count is approximate. It counts the characters the file asks to be drawn, and some fonts encode each character as two bytes, which can roughly double the figure. Measured against Apple's own PDF text extractor on this page's test set, the count ran about 1.9× high on a document using that encoding while every verdict still matched. The presence or absence of a text layer is exact; the number beside it is an estimate, and is shown here rather than above for that reason.
What the answer means
In a PDF, text is drawn by instructions: the standard describes a text object as "operators that may show text strings, move the text position, and set text state" (PDF 32000-1:2008, the PDF standard as published by Adobe, §9.4.1, read 23 September 2026). This check looks for those instructions.
"Has a text layer"
The words are stored in the file as text, so a text search has something to match. If searching still fails, the problem is the search, not the document — see why PDF search stops working.
"No text found — this looks like a scan"
The file has page images and no text-drawing instructions. There is nothing in the file that marks any of those pixels as letters, so there is nothing for a search to match. To make it searchable, the picture has to be run through OCR — optical character recognition — which looks at the shapes and writes a text layer underneath. This page does not run OCR and cannot make your file searchable; it only tells you which kind of file you have. That is what OCR is, and how you make a scanned PDF searchable.
"Contains both text and images"
The file has a text layer and it also has images. Which pages are which is not something this check can tell you — it reads the file as a whole, not page by page. If whole pages seem to be missing from your search results, those pages may be scans.
"Can't say for this file"
Parts of the PDF use a compression this page cannot read, so a "no text found" answer would not be trustworthy. The file may well be searchable.
"Encrypted — it may still be searchable"
The PDF standard allows "up to two passwords": an owner password and a user password. A reader first tries to open an encrypted file with the default, empty user password, and only "If this authentication attempt fails" should it "prompt for a password" (PDF 32000-1:2008, the PDF standard as published by Adobe, §7.6.3.1, read 23 September 2026). So a file with a real user password asks for it, and nothing inside can be read until it is entered. A file restricted only by an owner password — limits on printing or copying — opens without a prompt, and DocFind treats it as an ordinary document, indexed and searched like the rest.
This page reports that a file is encrypted but does not try to tell the two apart; doing so means attempting the decryption itself, which is more than a web page should do with your document. The quickest test is the one you can run yourself: open it in any reader. No password prompt means it will search normally.
The honest limits — ours and OCR's in general
- Handwriting is not recognised. DocFind's recognisers are built for printed text. A handwritten page will not become searchable, here or in the app.
- Scanned pages in other scripts depend on the platform. On Android, the recogniser bundled with the app reads Latin-script printed text only, so a scanned Chinese, Arabic or Hindi page will not become searchable there. On iPhone, scanned Chinese, Japanese, Korean, Arabic and Thai pages can be read. A scanned Hindi page — or any page in Devanagari — cannot be read on either platform.
- Text that is already in the file is a different case. A PDF that already holds Chinese or Arabic as text searches normally on both platforms. Devanagari text (Hindi, Marathi) is not matched reliably, even when it is stored as text.
- Search matches what you type. DocFind looks for the word you asked for; it does not guess at related words, so "running" will not find "run". That is deliberate — you can trust a hit.
- PDFs only. Word, Excel and plain-text files are not supported.
Or stop checking them one at a time.
DocFind searches inside many PDFs at once, and reads scanned pages by running OCR on your device. The index is built on the phone and stays there; nothing is uploaded, and on iPhone DocFind itself contains no networking code — searching, indexing, OCR and export never touch a connection. iPhone and Android.