Searchable PDF

What actually makes a PDF searchable?

A PDF file can hold two very different things that look identical on screen. Either it carries real characters with a font and a position, and then any search finds them instantly. Or it carries a photograph of the page, and then your computer sees exactly what it sees in a holiday snapshot: colour values. A document scanner always produces the second kind.

A searchable PDF is both at once. The image stays where it is, and on top of it sits a second layer holding the recognized words in the rendering mode called invisible. The reader never draws them, the search finds them anyway. That is why you can highlight a line in a well-made scan even though all you can see is pixels.

This tool builds exactly that layer. Optical character recognition finds the word boxes, then a piece of text is written into the page at each box position, squeezed or stretched in width to match. A screen reader can read the text out, and your document management system will index it.

How does recognition work inside the browser?

In two stages, and the first one is the one that matters. A specialized neural network first locates the areas that hold writing at all. Only then does a second network read each of those areas individually. That order sounds like a detail and is the difference between a usable and a useless result: a recognizer that sweeps the whole image blindly finds text lines in stamps, fold marks and coffee stains and writes gibberish into the text layer.

Both networks run as WebAssembly in the same tab as this page, with graphics card support through WebGPU where it is available. The one-time download is around twelve megabytes and lands in the browser cache. On the second document recognition starts immediately, and from then on the tool works with no internet connection.

Why do files blow up in other tools?

Because most of them do more than add text. They decode every page image, process it and encode it again, often with settings that differ from the original. A scan stored as a heavily compressed black-and-white image comes back as a general colour image. That is the point where a hundred and eighty megabytes turn into three gigabytes, and the user only notices from the file size afterwards.

We never open the page images at all. Recognition works on a temporary raster that is discarded after each page, and only text instructions go into the file. Growth therefore stays in the range of a few kilobytes per page. Since this is exactly where the alternatives fail, we put the number in the result: size before, size after, growth in percent.

What happens to pages that already have text?

They are skipped, and the report tells you how many. It sounds like a small thing and is the most common silent regression in tools that recognize every page blindly: a second, guessed text layer lands on top of the existing, correct one. After that, search finds every word twice, selection jumps, and copying gives you the text in duplicate.

The check runs per page, not per document. A contract where only the signed last page was scanned gets its text layer exactly there and nowhere else. If you would rather not have that, switch the option off.

How do I check that the text layer sits correctly?

Use Check the text layer. After the run the tool draws the recognized word boxes as outlines over a preview of the page. If the outlines sit on the writing, the text is in the right place. If they sit beside it or visibly too high, something went wrong, and you see it before the file goes into your archive.

Practically no provider offers this check, even though a shifted text layer is a well-known defect. It turns up in user forums regularly, usually with the same description: you select a sentence and end up selecting half the page, because the order of the boxes does not follow reading order. Showing nothing does not mean having fewer errors, it means not showing them.

Where does the tool deliberately stop?

It does not edit images. No deskewing, no rotating, no noise removal, no re-compression. If you want a crooked scan straightened, run an image tool first. The benefit of that restraint is the same one as above: what is never re-encoded can never be blown up.

It also does not rebuild layout. The text layer follows the recognized boxes, it does not detect paragraphs, columns or tables. If you need structured text, use PDF to Markdown. Handwriting is not recognized, the model is trained on print. And no PDF/A comes out of this, see the FAQ above.

Which related tools are there?

• PDF to Markdown: when you need the structure rather than the page, with headings, lists and tables.
• Image to Text: for a single photo or screenshot, when you only want the text and not a PDF.
• PDF Compressor: lossless structural optimisation, for a file that grew unnecessarily large after many editing steps.