Every office has them. Filing cabinets full of scanned contracts, invoices from 2019, insurance claims converted to PDF at the copier. The documents exist digitally, technically , but they're images wrapped in PDF containers. Ctrl+F returns nothing. Full-text search returns nothing. The information is trapped behind pixels.
The standard fix is a cloud OCR service. Google Document AI, AWS Textract, Azure Form Recognizer - upload your files, get text back, pay per page. It works. But if those scanned PDFs contain employment contracts, patient records, financial statements, or legal agreements, you've just sent confidential documents to a third-party server. For some organizations, that's a non-starter.
This post walks through how a complete scanned document search pipeline works when it runs entirely on your own hardware. No cloud APIs. No external network calls. Every step - from detecting whether a PDF is scanned, to extracting text, to making that text searchable - happens locally.
Why Cloud OCR Isn't Always the Answer
Cloud OCR services are accurate and fast. That's not in dispute. But they create two problems that certain organizations can't work around.
The documents leave your network. A scanned employee contract uploaded to a cloud OCR endpoint is now on someone else's infrastructure. The processing may take milliseconds, but during that window, the raw document data exists outside your control. For legal firms handling privileged communications, HR departments processing personnel files, or any organization subject to data residency requirements, this matters.
Volume costs add up. Cloud OCR charges per page. A 200-page scanned contract costs more than a 5-page memo. Run a few thousand archived documents through the pipeline and you're looking at recurring costs that scale with your document backlog - a backlog that only grows.
Self-hosted OCR removes both problems. The documents stay on your machines. The cost is your hardware.
The Pipeline: Scanned Image to Searchable Text
Making scanned documents searchable requires four steps. Each builds on the previous one.
Detect Whether a PDF Is Actually Scanned
Not every PDF needs OCR. A PDF exported from Word contains selectable text - standard text extraction handles it fine. A PDF created at a scanner is just stacked images. Running the same extraction on both wastes time and produces worse results.
The detection approach is straightforward: try extracting text from the first few pages using a standard PDF reader. If you get fewer than a couple hundred characters across three pages, the document is almost certainly scanned. This catches the vast majority of image-based PDFs without requiring any image analysis.
There's a useful edge case here. Some PDFs are technically text-based but produce almost nothing when parsed - corrupted exports, text rendered as vector curves, forms with fields stored as images. A good pipeline checks after standard extraction and falls back to OCR if the text yield is suspiciously low (say, fewer than 100 characters from what should be a multi-page document).
Extract Text With Local OCR
Each page of the scanned document gets converted to an image and processed through an OCR engine. Tesseract is the standard open-source choice. Originally developed at HP in the 1980s, now maintained by Google's open-source program, it supports over 100 languages and runs completely offline once installed.
For multi-page scanned PDFs, memory management matters. The right approach is processing one page at a time: convert a single page to an image, run OCR, store the extracted text, discard the image, move to the next page. Loading a 200-page scanned contract as 200 simultaneous images will exhaust your memory.
A few details that affect text quality:
Language packs aren't optional - If your documents mix languages - English contracts with Spanish appendices, for instance - the OCR engine needs the corresponding language data installed. Tesseract supports this through language pack combinations (English plus Spanish for example). Without the right packs, accuracy drops noticeably on non-English text.
Most scans don't need preprocessing - Tesseract handles moderate scan quality internally - slight skew, mild noise, typical copier output. Manually deskewing or binarizing every image before OCR is usually unnecessary. The exceptions are severely degraded originals: faded thermal paper, heavy coffee stains, documents that went through a flood. Those need help.
It's not just PDF - The same OCR step works on standalone images - PNG, JPG, TIFF, BMP. Photographed whiteboard notes, individual receipt scans, single-page documents that were never combined into a PDF. If the image contains printed text, the pipeline handles it.
Break the Text Into Searchable Pieces
OCR output from a 50-page scanned contract is one continuous wall of text. If a search engine has to match your query against that entire wall, it either returns everything or nothing. Not useful.
The system breaks the extracted text into shorter passages - roughly paragraph-length - so that when you search, you get back the specific section that answers your question, not the entire 50-page document.
The trick is where to split. You can't just cut every thousand characters and call it done - that would slice sentences in half, and a passage starting with "...shall not exceed the amount specified in Section 4.2" is meaningless without knowing what "the amount" is. A good system splits at natural boundaries: paragraph breaks, line breaks, ends of sentences. It also builds in slight overlap between consecutive passages, so information that falls near a boundary still shows up in search results.
Make It Searchable
This is where scanned documents stop being dead files and start being useful. Each passage gets indexed so the system understands what it means - not just what words it contains.
That distinction matters. Search for "termination clause" and the system finds passages discussing "conditions for ending the agreement," even if those exact words never appear in the OCR text. It understands the meaning behind your question, not just the keywords.
This is especially important for scanned documents because OCR isn't perfect. A scanner might read "cl" as "d" or "rn" as "m." Keyword search breaks on these errors - the exact string doesn't match. Meaning-based search tolerates them because the surrounding context still points to the right answer. The system runs both methods together and combines their scores, covering both failure modes.
After the initial search returns a batch of candidate passages, a second ranking pass scores each one against your original question to push the most relevant results to the top. For scanned documents where text quality varies page to page, this second pass makes a noticeable difference.
What This Looks Like in Practice
You upload a 120-page scanned contract - a PDF your office scanner produced a few years ago. The system checks the first three pages, finds almost no extractable text, and classifies it as scanned. It converts each page to an image one at a time, runs Tesseract on each, and assembles the extracted text. That text gets split into overlapping chunks, each chunk gets embedded, and the embeddings go into the vector database.
Later, you search: "What's the penalty for early termination?"
The system runs your query through hybrid search - keyword matching to catch the exact phrase if it exists, semantic matching to find paraphrased versions - then reranks the top candidates for relevance. You get the three most relevant passages from that contract and from any other scanned documents in the same collection, with the surrounding context.
No cloud service touched the file. It never left your server.
What Hardware Do You Need?
Less than you'd think. The OCR step (converting scanned images to text), runs on regular CPUs. No special graphics card required. More processor cores means the system scans pages faster, but any modern server handles it.
The AI component that understands your questions and finds relevant answers benefits from a GPU but works without one. Without a GPU, the AI is slower to respond. The scanning, text extraction, and search still work at full speed.
A practical starting point: a server with 32 GB of memory, 8 or more processor cores, and enough storage for your documents. Adding an NVIDIA GPU speeds up the AI responses noticeably but isn't mandatory.
The one thing to plan for: the initial processing of your document backlog. A 500-page scanned contract takes real time to process page by page. But once a document is processed, it's indexed permanently. Searching is fast after that, regardless of how many documents you've added.
How Selvo Lens Handles This
Selvo Lens runs this entire pipeline on your infrastructure as a self-hosted deployment. You upload a scanned PDF or image, and the system handles everything described above automatically - detection, text extraction, indexing, search.
A few specifics worth knowing:
It recognizes scanned PDFs automatically - You don't need to sort your files into "scanned" and "normal" piles before uploading. The system checks each PDF and routes it through OCR when needed. If a standard text extraction produces suspiciously little output, it retries with OCR as a fallback.
It handles images directly - not just PDFs. Photograph a whiteboard, scan a receipt, upload a TIFF from an old archive. PNG, JPG, TIFF, BMP, GIF all work.
It supports 119 languages out of the box. Documents that mix languages, an English contract with a Spanish appendix, get processed correctly without manual language selection.
It processes documents page by page, so a 2,000-page scanned archive doesn't require loading the entire file into memory at once.
What it doesn't do - It doesn't recognize handwriting, only printed text. It extracts text from scanned tables, but the table structure (rows and columns) gets flattened to plain text. And we haven't published accuracy benchmarks comparing our OCR output against cloud services like Google Document AI or AWS Textract. These are real limitations to weigh when deciding between a local and cloud approach.
The Bottom Line
Scanned documents don't have to stay unsearchable, and making them searchable doesn't require sending them to someone else's servers. The technology to extract text locally, index it, and search it by meaning (and not just keywords), exists today and runs on standard hardware.
The real question isn't whether local OCR works. It does. The question is whether your organization's sensitivity requirements, document volume, and budget make the self-hosted route worth it compared to a cloud service. For many companies sitting on filing cabinets of scanned contracts and archived records they can't search, the answer is straightforward.