OCR PDF: Make a Scanned PDF Searchable

Add an invisible, positioned text layer to every page of a scanned PDF so you can search, select and copy it. Free, runs on your own device.

🌐 Español

Drop your file here (.pdf)

🔒 Private by design: your files are processed locally in your browser and never uploaded to any server.

Written and maintained by Last updated

Pixels that look like letters, and the layer that finds them

A scanned page is a photograph of writing. To you it reads as a contract or an invoice; to every program that opens it, it is a rectangle of coloured dots with no text in it whatsoever. That is why a keyword search finds nothing, why you cannot drag a cursor across a clause to copy it, and why pasting a scanned page into anything text shaped gives you an image.

Optical character recognition reverses that. The pixels are analysed, characters are reconstructed, and the recovered words are written back into the PDF as a text layer marked invisible, positioned so each word sits over the printed word it came from. Your eyes see the scan exactly as before. A search box sees real text.

Three pieces do the work here, all inside the page you are reading. PDF.js, the renderer behind Firefox’s built in PDF viewer, draws each page onto a canvas. Tesseract, the open source recogniser that began at HP and later spent years under Google’s stewardship, compiled to WebAssembly, reads that canvas. pdf-lib then writes the words back into the original document. Your file is never sent anywhere; the recogniser’s own code, its WebAssembly core and the trained model for the language you pick are what get downloaded, once, from public package CDNs when you first run a job.

From scan to searchable copy, step by step

  1. Drop your scanned PDF onto the box, or press “Choose a file”. One document per run, and only a .pdf is accepted.
  2. Set “Text language” to the language actually printed on the page. English is preselected.
  3. Set “OCR resolution” to “Faster (100 DPI, lower accuracy)”, “Recommended (150 DPI)” or “Most accurate (300 DPI, slowest)”.
  4. Press the button, which reads “OCR PDF: Make a Scanned PDF Searchable”, the same wording as the page title, and leave the tab open while the bar fills.
  5. Download the result. A file called report.pdf comes back as report-searchable.pdf, looking the same and answering to a text search.

The progress bar is driven by the recogniser’s own reporting and is spread across the page count, so on a twenty page document the first page finishing moves it to roughly five percent. It is not guessing.

One CPU core, and the speed to plan for

This is one of the heaviest jobs on the site, and the reason is structural rather than fixable. Browsers only unlock multi threaded WebAssembly for pages that send the COOP and COEP response headers, and those headers break the display ads that keep everything here free. In this case the point is moot anyway: the Tesseract core package ships only single threaded WebAssembly builds, so there is no threaded variant to select even if the headers were available. Recognition runs on one core.

For a sense of scale, the measurement taken while this tool was built put recognition at roughly 300 milliseconds for a 58 word, roughly one megapixel test image, after a one time worker startup of about 400 milliseconds. A dense full page carries far more than 58 words, and every page in your document pays both a rasterisation pass and a recognition pass, so a long scan can run for minutes. Try a two or three page document first and extrapolate from what your own machine does.

There is no per page error handling either. If one page fails to render, the whole run stops and the shell shows its one generic failure message, with the real reason logged to the browser console. Nothing partial is recoverable.

Where each recognised word lands on the page

The coordinate work is the interesting part. The recogniser reports a box for every word in the pixel space of the rasterised canvas, measured from the top left. A PDF page measures from the bottom left, in points. Dividing the pixel measurements by the render scale converts them back to points, and subtracting from the page height flips the axis, which puts the word where it belongs on the untouched original page.

Two honest limits fall out of this. The invisible run’s size is taken from the height of the word’s box, which is a stand in for real font metrics rather than a reconstruction of them. And the invisible text is set in Helvetica, so on the rare occasion the recogniser produces a character that font cannot encode, that single word is skipped rather than the whole page’s layer being abandoned. A page where nothing at all is recognised gets no layer added and passes through untouched.

Extracting text against baking it in

The neighbouring tool, Extract Text from Image (OCR), runs the same recogniser but answers a different question. It takes images, several at once, and hands back a plain .txt file of what it read. It will not take a PDF at all, since its accepted list is image extensions only. Use it when you want the words and nothing else.

This tool is for when you want to keep the document. You get a PDF back, page for page identical to look at, that now answers to a search box, lets you select a paragraph and lets you copy a clause. Downstream, that changes what other tools can do with it.

Two useful pairings. If your source is paper rather than an existing file, capture it with Document Scanner with Webcam first, which flattens the perspective and exports a multi page PDF this tool accepts directly. And if you only ever need the pages as pictures, for instance to attach a single sheet to an email, Convert PDF to JPG is the shorter route, though a multi page document comes back from it as a ZIP. The rest of the document tooling sits on the PDF tools hub.

The documents people actually run through this

The scans worth making searchable tend to be the ones you would least like to hand to a stranger’s server: a signed lease, a scanned passport page, a medical form, years of bank statements. Doing the recognition locally is what makes those safe to process at all, and it is also why the honest speed warning above matters. Nothing about the trade is hidden. You spend your own CPU time instead of someone else’s, and in exchange the document stays where it is.

Beyond that, the everyday uses are unglamorous and useful: finding one clause in a photocopied contract without rereading it, pulling amounts out of scanned receipts for bookkeeping, or turning a shelf of digitised paper records into an archive you can search through rather than open one file at a time.

Frequently asked questions

Does the finished PDF look different from the one I put in?

It should look identical, because the original document is opened and kept rather than rebuilt. Nothing is redrawn, re-compressed or flattened into images; the only thing added to each page is a run of text marked with the PDF rendering mode that paints nothing at all. A viewer will find and highlight those words, but there is no visible ink for them.

Which resolution should I pick?

Start with the middle option at 150 DPI. That number sets how large each page is rasterised before recognition runs, as a multiple of the PDF's native 72 points per inch, so 300 DPI hands the recogniser roughly four times as many pixels per page and costs roughly that much more time. Small print and faint photocopies are the cases where the extra pixels genuinely pay for themselves.

Why is only one file accepted at a time?

That is a deliberate limit rather than an oversight. Every page needs its own rasterisation pass and its own full recognition pass, so allowing a queue of documents would multiply an already heavy job with no warning. If you have several scans to process, run them one after another and watch how the first one behaves on your hardware before committing to the rest.

What happens if I press Cancel halfway through?

The run stops between pages and the recognition worker is shut down, which frees the memory it was holding. Nothing partial is kept, because the file box empties and there is no half-finished PDF to download, so a cancelled job has to be started again from the beginning. That is the shared file shell's behaviour, not something specific to this tool.

Does the recognised text line up exactly with the printed words?

Closely, but it is an approximation and worth stating plainly. Each recognised word gets its own positioned text run, sized from the height of the box the recogniser drew around it rather than from the real font's metrics. Selection highlighting therefore sits roughly, not perfectly, over the printed glyphs, and how a viewer joins those runs back into lines when you copy depends on that viewer's own heuristics.

Can it handle a language that is not in the list?

No. Five trained models are offered and anything else falls back to English, which produces poor results on text it was not trained for. The list matches the one the image based text extraction tool on this site uses, and it is short on purpose because each model is downloaded on demand and each has been checked rather than merely enabled.

Related tools