Scanned PDFs contain only image data. Search finds no text because there is no text. Run the file through OCR to add a real text layer. The page looks the same, but search, copy, and screen readers all start working.
You open a scanned contract, hit Ctrl-F, type a word you know is on the page, and the reader says "no results". You can see the word right there. The reader claims it does not exist. Both statements are true. Understanding why is the whole story.
A PDF is two documents in one
Every PDF page is capable of holding two separate layers. Almost nobody who uses PDFs thinks of it this way, but it explains every scan-related frustration you have ever had.
Real characters underneath
- Text is stored as actual characters, not pixels
- Search finds every occurrence
- Copy-paste produces real text
- Screen readers can read aloud
- Zooming keeps letters crisp at any level
Just an image on the page
- Only pixels, no character data
- Search finds nothing
- Copy-paste grabs the whole page as one lump
- Screen readers have nothing to read
- Zooming reveals blurry pixels, not sharp text
When you scan a paper document, your scanner takes a photograph of each page and wraps those photos in a PDF container. The reader treats each page as one big image. The "text" you see is really just patterns of pixels arranged to look like letters. There is no character data stored anywhere in the file.
The three-second test
Not sure if your PDF is a scan or real text? Try this before doing anything else.
Open the PDF in any reader
Adobe, Preview, Chrome, whatever you already have. It does not matter which one.
Click and drag on a single word
Pick a word in the middle of a paragraph, not a heading or logo.
Watch what gets selected
If the word highlights cleanly by itself, the PDF has real text. If the cursor grabs the whole page as one blue rectangle, the PDF is a scan.
What OCR actually does
OCR stands for optical character recognition. It is the software equivalent of what your brain does when it reads a scanned page: look at the pixels, recognise letter shapes, decide what each character is.
Running a scan through OCR does not change what the page looks like. It adds an invisible text layer positioned behind the image. When you search or copy, the reader consults that hidden layer. When you look at the page, you see the original image on top. Best of both worlds.
Typed text at 200 to 300 DPI, standard Latin scripts, no coloured backgrounds.
Browser-based OCR, no network round-trip. Scales linearly with page count.
The text layer is compact. Compression can offset it if size matters.
What affects OCR accuracy
OCR is not magic. It works best on scans that look the way a scanner-manufacturer imagined. When the input drifts from that ideal, accuracy drops in predictable ways.
- Resolution. 200 to 300 DPI is the sweet spot. Anything under 150 DPI struggles on small fonts. Anything over 600 DPI is wasted effort and larger files with no accuracy gain.
- Contrast. Black on white works best. Faded receipts, coloured backgrounds, and low-contrast originals produce more errors.
- Font. Standard sans-serif and serif fonts are easiest. Handwriting, calligraphy, and heavily stylised display fonts are much harder.
- Skew. Pages scanned at a slight angle confuse letter-detection. Straighten before running OCR when possible.
- Language. OCR engines need to know which language they are reading. English, French, German, Spanish, and most Latin-script languages work with any tool. CJK languages need language-specific models.
- Layout. Simple single-column pages OCR cleanly. Newspapers, magazines, and forms with mixed columns produce reading-order surprises that need cleanup.
Running OCR without uploading the file
Most online OCR services want you to upload the file to their server. For anything sensitive (contracts, medical records, legal filings, tax documents), that is a real problem. The alternative is to run OCR in your browser.
Tesseract, the long-standing open-source OCR engine, has been compiled to WebAssembly, so a handful of tools can now run recognition inside the browser tab itself. The file never leaves the device, and the language model is downloaded once and cached, which makes the second document faster than the first. PDFslime does not currently offer OCR, so this is one to handle in a dedicated OCR tool.
What you can do once OCR is done
Once your PDF has a real text layer, features you never had suddenly work.
- Find text anywhere in the file. Ctrl-F now surfaces every occurrence, not just the ones your eye caught.
- Copy paragraphs into other documents. Highlight, copy, paste into Word or Notes. Real text, real editing.
- Screen readers work. Blind and low-vision users can consume the document. Accessibility compliance actually becomes possible.
- System-level indexing. macOS Spotlight and Windows Search can index the content, so the whole file surfaces in future searches.
- Cross-document search in DMS. Document management systems, note-taking apps, and cloud storage can index the text and find it years later.
- Machine translation and summarization. Any tool that needs text to work now works, from translation apps to reading assistants.
Edge cases and workarounds
Handwriting
Traditional OCR engines struggle with handwriting. If the file is mostly typed text with a handwritten signature or a few notes, run OCR normally and accept that those handwritten portions will not be captured. If the file is entirely handwritten (personal notes, historical documents), OCR results will be too rough to be useful without heavy cleanup.
Multi-language documents
A page with English text and a Spanish quote works if you run OCR with English + Spanish selected. A page with English text and a Chinese character or two needs multi-model OCR to catch both. Most browser OCR tools let you pick multiple languages at once, at some accuracy cost per additional language.
Very old or damaged scans
Faded typewriter carbons, low-contrast microfilm captures, or damaged historical documents may need image preprocessing (contrast enhancement, deskew, despeckle) before OCR. Some tools do this automatically. If yours does not, try running the scan through an image editor first.
Add the text layer your scan is missing
Recognition runs in your browser. The scan is never sent anywhere.
Common questions
Details that come up when running OCR for the first time.
01How do I know if my PDF is a scan or real text?
Try to select a single word by clicking and dragging with your mouse. If the cursor highlights one word cleanly, the PDF has real text. If the cursor grabs the whole page as one image, the file is a scan without a text layer. You can also try Ctrl-F for a word you can see. No results means no text layer.
02What does OCR actually do?
OCR reads the pixels on the page and recognises letters. It then adds a text layer underneath the visible image so that search, copy, and screen readers all work. The page you see stays identical. The change is invisible until you try to interact with the text.
03How accurate is browser-based OCR?
Around 95 to 99 percent on clean scans of typed text at 200 to 300 DPI. Accuracy falls on faded scans, handwriting, unusual fonts, and low-resolution captures. Latin scripts work well, CJK languages need language-specific models.
04Will OCR change how the file looks?
No. The visible image stays untouched. A text layer is added invisibly behind it. Zoom, print, and appearance are identical to the original.
05Does OCR increase file size?
A small amount, typically under 10 percent. The text layer is compact compared to the image data. If the growth matters, compress after OCR.
06Does PDFslime upload the file for OCR?
No. Our OCR tool runs Tesseract via WebAssembly inside your browser tab. Files are read into local memory, processed locally, and never leave the device.