# Scan a PDF for Text: How Search Inside a PDF Works

- Author: Schema Law (https://www.schemalaw.com/)
- Published: 2024-08-03T20:16:51Z
- Updated: 2026-10-11T19:22:20Z
- Category: OCR basics
- Canonical: https://www.schemalaw.com/blog/scan-a-pdf-for-text

> To scan a PDF for text, your reader matches what you type against characters stored in the file. How that works, the options, and why searches come up empty.

To scan a PDF for text, open it and press Ctrl+F (Command+F on a Mac), then type the word or phrase. The reader compares what you typed with the characters stored in the file. If the pages are pictures with no stored characters, or the stored characters differ from what you see, the search finds nothing.

That second sentence is the whole subject. Search never looks at the page the way you do. It looks at a list of characters that travels with the page, and every puzzling result, from zero hits to a highlight in the wrong place, comes from a gap between that list and the picture.

## How does a PDF reader scan a file for text?

A PDF reader scans a file for text by pulling the stored characters out of each page, joining them into words and lines, and comparing that string with the one you typed. It does not examine the image. A page with no stored characters gives the reader nothing to compare, however clear the print looks.

The work happens in three steps, and each can go wrong on its own.

1. **Extract.** The reader walks through the page's instructions and collects every character the file tells it to draw, along with where each one goes. In a PDF saved from a word processor these are the visible letters. In a scan that has been through OCR they are invisible letters stored behind the picture.
2. **Assemble.** A PDF does not have to store spaces or line breaks. Often it stores "place these letters here, then these letters there". The reader works out from the positions which letters form a word, where a space belongs and which line follows which. Different readers make these guesses slightly differently.
3. **Compare.** The reader slides your search term along the assembled text, usually ignoring upper and lower case, and reports each place the characters agree.

So when you scan a PDF for words, you are searching the assembled string from step 2. You never see that string unless you copy a page and paste it somewhere. That is why pasting a page into a plain text editor is the best diagnostic for a search that misbehaves: it shows you what the reader is really searching.

### When there is nothing to scan

If a reader reports no matches for a word that is plainly on the page, try to select that word with the cursor. If nothing highlights, the page holds no characters and the fix is OCR, not a different search term. The post on [what readable means for a PDF](https://www.schemalaw.com/blog/how-to-make-pdf-readable) sets out the kinds of text a file can and cannot have.

Some files lack text by design. A sender may have flattened the pages to pictures so the content cannot be searched or copied, and the post on [converting a PDF to a non-searchable PDF](https://www.schemalaw.com/blog/convert-pdf-to-non-searchable-pdf) explains why people do that. You can still run OCR on such a file yourself.

## Scanning one PDF for a word versus scanning a whole folder

Scanning one open PDF is a live comparison: the reader reads the file's text now and reports hits in seconds. Scanning a folder works in one of two ways. Either a program opens every file in turn, which is slow and thorough, or it consults an index built earlier, which is fast and only as good as the index.

| | Find in one open file | Search across a folder, file by file | Search through an index |
| --- | --- | --- | --- |
| Where you run it | The find box in your PDF reader | An advanced or multi-file search in a PDF program | The operating system's search, a document management system, a review platform |
| What it reads | The text of the open file, at that moment | The text of each file, at that moment | A word list made when the files were indexed |
| Speed on 2,000 files | Not applicable | Minutes or longer | Seconds |
| Sees a file added a minute ago | Yes | Yes | Only after the index updates |
| Finds part of a word, such as "indemn" | Usually | Usually | Depends on the system; many match whole words or word stems |
| Image-only PDFs | No hits, silently | No hits, silently | No hits, silently, unless the system ran its own OCR |

The last row matters most. Every method reports "no results" for an image-only file in the same quiet way it reports "no results" for a file that truly lacks the word. Nothing tells you that 300 of the 2,000 files were never searched in any meaningful sense.

### Counting the files a folder search could not read

Before you trust a folder-wide search, find out how many files had no text to search.

1. Pick a word that appears in nearly every document in the set. In an English-language production, "the" works. So does the name of the producing party if it is in a footer.
2. Run the folder search for that word and note how many files return a hit.
3. Compare that number with the total count of PDFs in the folder.
4. The files with no hit are your blind spot. Open three of them. They will usually be image-only scans, or scans with a text layer so poor that even a common word is missing.
5. Run OCR on those files and repeat the search.

Suppose a folder in the fictional matter *Pruitt v. Alder Ridge Storage* holds 412 PDFs and a search for "the" returns 371 of them. Forty-one files were invisible to every search you ran before. If your earlier search for "Pruitt" came back with nine documents, the accurate statement is "nine of 371 searchable documents", not "nine of 412".

Across a folder, look in a pleading for the party name, then in a court opinion for its citation and the statute discussed there. A hit means those characters are stored. A miss can mean the opinion has no text yet, or that the section sign inside the citation was lost in recognition.

An index adds one more question: when was it built, and what did it do with files that had no text? Some systems run recognition on image files as they index them and some skip them. Ask whoever administers yours.

## Why does a PDF search highlight the wrong spot on the page?

A PDF search highlights the wrong spot when the stored text and the page picture are out of step. The reader draws the highlight where the file says the matching characters sit. If those positions were recorded loosely, or the picture was changed after the text was added, the highlight lands beside the word, on another line, or nowhere visible.

In a PDF saved from a word processor this almost never happens, because the visible letters are the stored letters. It happens in scans, where the text was added afterwards by OCR. The usual causes:

- **The text was placed per line or per page, not per word.** Search still finds the right page, and the highlight covers a strip or sits at the top. The post on the searchable PDF sets out the three levels of placement under [how the hidden text is lined up with the picture](https://www.schemalaw.com/blog/searchable-pdf#how-is-the-hidden-text-of-a-searchable-pdf-lined-up-with-the-picture).
- **The hidden letters are a different width from the printed ones.** The hidden text is set in one font and the print in another. Over a long line the difference adds up, so the highlight slides further off toward the right margin.
- **The page was straightened or cropped after OCR.** If someone deskewed, rotated or trimmed the images later, the picture moved and the text did not.
- **The scan was skewed and the text was laid out level.** On a tilted page the hidden line drifts away from the printed line as it crosses the sheet, so highlights are right at the left margin and a line off at the right.
- **Two text layers are present.** A copier added one, a later tool added another. The reader may highlight a match from the older, misplaced layer.
- **The word was found somewhere you were not looking.** Hidden text can sit in a header, a stamp or a margin note region. The hit is real and the location surprises you.

A misplaced highlight is an inconvenience. It tells you about position, and it says little about whether the text itself is accurate. Once the search has taken you to the page, read the page.

The searchable PDF that Schema Law exports is described on its [export formats list](https://www.schemalaw.com/#formats) as your original file with a hidden text layer, so search finds the page. Treat the search as a way to reach the page, then locate the word by eye.

## Exact match, case, whole words and phrases in PDF search

By default, most PDF readers ignore case and match any run of characters, so "act" finds "contract" and "Act". Options for case and whole words narrow the match. A phrase is matched as one string, spaces included, so it succeeds only where the stored text has those words in a row with ordinary spaces between them.

| Option | What it changes | Useful for | The catch |
| --- | --- | --- | --- |
| Default, no options | Any run of characters, any case | A first pass; partial names | Short terms flood you with hits inside longer words |
| Match case | Upper and lower case must agree | Defined terms such as "Premises"; acronyms such as "ERA" | Misses the term in an all-capitals heading |
| Whole words only | The match must start and end at a word boundary | Short words and initials: "Lee", "Ms", "art" | Fails where OCR dropped or added a space |
| Phrase | The words in sequence, as typed | Clause titles, full names | Fails across a line break, a column or a page |
| Include comments or bookmarks | Also searches notes and the outline | Annotated working copies | Hits in a comment are not in the document itself |

A few habits get more from these controls.

**Search the distinctive part.** For "Marguerite Okonkwo-Baird", search "Okonkwo". One unusual word survives line breaks and spacing faults that defeat a full name.

**Run numbers more than one way.** An amount printed as $18,450.00 is stored however it was read. Try "18,450", "18450" and "18 450".

**Change one option at a time.** If "whole words only" turns twelve hits into two, the ten that vanished are worth a look. They are often real occurrences with a spacing fault.

**Know what your reader cannot do.** A basic find box has no wildcards, no "either of these words" and no proximity search. Searching for *Okonkwo within ten words of terminate* needs a program built for it, such as a review platform or an indexed search tool.

## What breaks a match: line-end hyphens, ligatures and odd spacing

A match breaks when the stored characters are correct in substance and still not the characters you typed. A word split by a hyphen at a line end, a pair of letters stored as one joined symbol, or a space in an unexpected place will each hide a word that anyone can see on the page.

These faults differ from recognition errors, where OCR read a letter wrongly. Those are covered in the section on [why search still misses words after OCR](https://www.schemalaw.com/blog/how-to-make-a-scanned-pdf-searchable#why-search-still-misses-words-after-ocr). The faults here turn up in clean scans and even in PDFs that never went near a scanner.

| What is on the page | What the file may store | Your search for... | Result |
| --- | --- | --- | --- |
| "indemni-" at a line end, "fication" on the next | `indemni-` and `fication` as separate pieces | indemnification | Not found |
| "office" set in a book typeface | `o`, the single ffi symbol, `ce` | office | Not found in some readers |
| "final" in a typeset brief | `fi` as one symbol, then `nal` | final | Not found in some readers |
| A justified line with wide gaps | `T e n a n t` or `theTenant` | Tenant | Not found, or found only without "whole words" |
| "Tenant's" with a curly apostrophe | `Tenant’s` | Tenant's (straight apostrophe) | Not found in some readers |
| "Section 4.2" with a fixed space | A non-breaking space between the two | Section 4.2 | Not found in some readers |
| Letter-spaced heading "N O T I C E" | Each letter followed by a space | notice | Not found |

### Why each one happens

**Line-end hyphens.** The typesetter split the word to fit the line. A PDF records what was drawn, so the first half ends in a hyphen and the second half begins a new line. Some readers rejoin the halves when they assemble the text, and many do not.

**Ligatures.** Typefaces join certain letter pairs, most often fi, fl, ff, ffi and ffl, into a single shape. Some files store that shape as one special character. Readers that treat it as equal to the separate letters find your word, and others do not. OCR can produce ligature characters too, when it recognizes the joined shape as one symbol.

**Spacing.** Because a PDF may store no spaces at all, the reader infers them from gaps. Wide letter-spacing produces spaces inside words. Tight justified lines produce none between words. OCR adds its own spacing mistakes around punctuation, in dotted leader lines and in columns of figures.

**Look-alike characters.** Curly and straight quotation marks, different kinds of dash, and ordinary and non-breaking spaces look the same on the page and are different characters to a computer.

### Searching around the damage

- Search the longer half of a word that might be hyphenated: "indemni" or "fication".
- For a word containing fi, fl or ff, search a fragment that avoids the pair: "nancial" for "financial", or "duciary" for "fiduciary".
- Drop the apostrophe and search the stem: "Tenant".
- Turn off "whole words only" when a search for a common word returns suspiciously few hits.
- Paste the page into a plain text editor and look at how the word is actually stored. Then search for that.

## Should a legal search rely on scanning a PDF for words?

Use it to find things, and do not rely on it to prove something is absent. A hit is checkable: you can open the page and read it. A search with no hits only shows that the stored characters did not match your term. Over recognized text, that leaves room for the word to be on the page.

That asymmetry is the practical rule. Finding "Okonkwo" on page 212 of a production is a fact you can confirm by looking. Finding no "Okonkwo" anywhere tells you about the text layer first and the documents second.

The limits come from three places:

- **Coverage.** Image-only pages, handwriting and text inside photographs were never in the text at all.
- **Fidelity.** Recognition errors and the storage faults described above hide words that were read.
- **Vocabulary.** Keyword search finds the words you thought of. A memo that says "the storage arrangement" will not answer a search for "lease".

None of this is an argument against keyword search. It is an argument for knowing what your search covered. Before you report a negative result to a supervising lawyer, a client or a court, be able to answer these:

1. How many files or pages were in the set, and how many had usable text?
2. Was the text extracted from native files, or recognized from scans? If recognized, by what tool?
3. What spot checks were done on the text, and on which pages?
4. Which terms, spellings, fragments and number formats were searched?
5. Were the hardest pages (faxes, handwriting, tables, low-quality copies) read by a person?

Then phrase the result to match. "No occurrence of 'Okonkwo' or 'Okonkwo-Baird' found by text search of 371 text-searchable PDFs; 41 image-only files reviewed manually" is a statement you can stand behind. "The production does not mention her" is a larger claim than a search can carry.

What a party must do to search its own or another side's documents in a given matter depends on the governing rules, any protocol the parties agreed and the court. This post explains how the tool behaves. It is not advice on what a particular obligation requires, and you should check the rules and orders that apply to your matter.

If the scans in front of you have no text yet, add it before you search. The [three-step outline of how Schema Law works](https://www.schemalaw.com/#how-it-works) shows the upload, check and export sequence, and the on-screen pages let you compare the recognized text with the original before you depend on any search over it.

## Try it on a real document

Upload a scanned PDF and export it as Word, a searchable PDF or plain text on the free plan. Your documents are never used to train an AI model. [Start free](https://www.schemalaw.com/api/auth/google)