OCR PDF
Turn a scanned PDF into one you can search, select and copy from.
Drag & drop a scanned PDF here
or click to select a file — English printed text, processed in this tab
About OCR PDF
A scanned PDF is a stack of photographs. It looks like a document, prints like a document and is completely opaque to search, because there are no characters in it — only pixels arranged in the shape of characters. This tool reads those pixels and writes the words back in as real text, so the same-looking document starts answering Ctrl+F. The result downloads as searchable-yourfile.pdf and the original on your disk is untouched.
How the searchable layer is built
Each page is rendered to a canvas at two or three times its point size — 144 or 216 DPI — and handed to Tesseract, which returns not just the text but a bounding box and a confidence score for every individual word. A new PDF page is created at the original page dimensions, the rendered image is embedded as a JPEG covering it, and then each word is drawn on top as Helvetica in text rendering mode 3, the PDF way of saying “lay this text out but paint nothing”, under a zero-alpha graphics state as well.
Placing a word takes a little care, because the box Tesseract reports is the box of the ink, not of the em square. The font size is derived from the box height and the word’s own letters using Helvetica’s metrics — a word of x-height letters like “moon” implies a much larger font than its box is tall, while “Ml” reaches the full ascender — and the drawn word is then squeezed or stretched horizontally with the PDF Tz operator so that it measures exactly as wide as the box, which is the same mechanism Tesseract’s own PDF writer uses. The baseline sits on the bottom edge of the box, and drops by a descender’s depth only for words whose ink actually goes below it — anything containing a g, j, p, q, y, a comma or a bracket. The result is that a drag-selection covers the whole word and a search highlight lands on the ink rather than two thirds of it.
Words the engine scored below 30 out of 100 are dropped rather than placed. A low-confidence guess is not neutral: it makes the document findable under a word that is not there, which is more damaging in an archive than a small gap. The panel below the progress bar shows the full raw recognition for every page, including the low-confidence words, so nothing is hidden from you — only from the search index. One more filter applies at the last step: the invisible layer is written in the standard PDF WinAnsi encoding, so a character outside it — a CJK glyph, a Cyrillic letter — is dropped from the layer even though it still appears in the panel.
A per-word threshold cannot catch the case where the engine is confidently wrong about the whole page, which is what happens when a page is fed in sideways or upside down: every line is read as a column of unrelated marks, and enough of those marks score above 30 to fill the layer with nonsense. So the average score of the words that were placed is reported next to the page count, and if it comes out below 75 the result panel says plainly that the page probably was not readable and points at Rotate PDF. The separation is clean in practice — an upright page of printed type scores in the nineties, a badly blurred one still manages the low eighties, and a sideways page lands in the sixties. Orientation is not detected or corrected here; there is no page-orientation model in the English-only build, so that is a warning rather than a fix.
That average has a blind spot of its own, and it is worth knowing about, because it is the one number a hurried reader trusts. It is taken over the words that were placed, so a page of photographs that yielded a single legible caption scores in the nineties on the strength of that one word. A mean confidence therefore says how sure the engine was about what it found, never how much of the page it found. The word count is checked alongside it: a run that placed nothing at all is reported as exactly that rather than as a text layer added, with the download offered but plainly labelled, and a run that placed fewer than five words per page is called out as too thin to have made the document searchable. Both notes say what usually causes it — a page that really is only a picture, a scan too dark or too small to read, handwriting, or a script this build does not know.
Very large pages get one extra safeguard. Browsers refuse to allocate a canvas beyond a fixed pixel area — 268 megapixels on the desktop, far less on some phones — and they also cap each single edge at 16,384 pixels, and in both cases they hand back a blank canvas rather than an error, so an E-size plot or a long banner page at 3x would otherwise produce an empty image and recognise nothing. Pages that would cross either limit are rendered at whatever scale fits a 100-megapixel budget and a 16,384-pixel edge instead, and the result panel tells you how many pages that applied to. Ordinary paper sizes, including A0 at 3x, are never affected. If a browser refuses even the reduced canvas, you get a message naming the page rather than a run that never ends.
English, printed, and honest about it
One language model ships with this site — English — so that the entire pipeline can be served from our own origin and works on a locked-down network or with no connection at all once cached. There is no language selector, and pointing this at a document in Greek, Arabic, Hindi or Chinese does not raise an error: the engine returns plausible-looking rubbish, most of which the WinAnsi filter then drops, so what you get is an almost empty text layer rather than a useful one. Printed type is what the model knows. Handwriting, especially cursive, is not recognised in any useful sense.
Accuracy is set almost entirely by the scan. A flat, straight, evenly lit page of 10-point type at 300 DPI reads close to perfectly. A photograph taken at an angle, with a shadow across the gutter and the text filling a third of the frame, reads badly, and no option on this page fixes that — rescanning does. Faint carbon copies, heavy background tints, stamps overlapping text and skewed pages are the usual causes of a disappointing result. Where the resolution setting does earn its keep is small print: change it and press Run OCR again to compare, without re-picking the file.
What changes about the file
- Pages become images. Every page is rebuilt from the render, so anything vector in the original becomes a JPEG at your chosen resolution. For a scan that costs nothing, because it was already pixels; for a born-digital PDF it is a real loss.
- Size usually grows. JPEG page images at 144 DPI are bigger than a compressed scan of the same page in many documents. Run Compress PDF on the output if that matters.
- Annotations, forms, bookmarks and links are not carried over. The output is a freshly built document containing page images and the text layer, and nothing else.
- Metadata is not copied either, which is usually welcome — but if you needed the original Title and Author, set them again afterwards with PDF Metadata.
- A password-protected file is not opened at all. If the PDF asks for a password to view, run Unlock PDF first; one that only restricts printing or editing is processed normally.
When to use something else
If you can already select text in the document, it does not need OCR and running it here would make it worse. You will be told: the first three pages of whatever you drop in are checked for existing text, and a warning appears above the button before you spend a minute finding out. PDF to Text is the tool for that file, and it extracts the real layer with no error rate at all. If you only want the words and not a PDF, PDF to Text again for text-layer files, or Image to Text for a single photograph. If the source is a pile of photos rather than a PDF, Image to PDF will bundle them into one document that you can then bring back here. And if the document is confidential, note that everything above happens inside this browser tab: the renderer, the recognition engine and the PDF writer are all local, so the file is never uploaded.
A real invisible text layer
Every recognised word is drawn in invisible text at the left edge and baseline of the box Tesseract reported, sized from the box height and horizontally scaled so it measures the same width as that box. Search, select and copy land on the whole word; nothing changes visually.
Page image plus text, not text alone
Each page is rendered at 144 or 216 DPI, embedded as a JPEG and given its text layer, at the original page size in points. Unusually large pages are rendered lower so the browser can still rasterise them, and the result panel says when that happened.
Per-page progress, English LSTM engine
A bar tracks recognition page by page so a fifty-page scan is never a blank screen, and Stop ends a run you did not mean to start. Recognition runs on the neural line recogniser with the English model served from this site, not a CDN.
It tells you when it is the wrong tool
A file that already has real text is spotted when you drop it in, before you spend a minute rasterising a document that did not need it. A page the engine could not actually read — nearly always one lying on its side — is called out by its confidence score instead of quietly filling the layer with nonsense. And a run that found nothing, or almost nothing, says so rather than showing you a green tick over an unsearchable file.
Nothing leaves the tab
Rendering, recognition and PDF assembly all happen in your browser. A scanned contract, medical letter or bank statement is never uploaded, queued or stored anywhere.
Frequently Asked Questions
What does the output PDF actually contain?
Two layers per page. The visible layer is a JPEG of the page rendered at your chosen resolution. Behind it sits every recognised word, drawn as real text in the position the engine reported but painted with nothing — PDF text rendering mode 3, plus a zero-alpha graphics state. That is the standard construction for a searchable scan: it looks identical to the original, and search, text selection and copy-paste all work.
Will the file get bigger?
Usually yes, sometimes dramatically. The original pages are replaced by JPEG images at 144 or 216 DPI, so a small vector PDF can grow several times over, while a scan that was already a bundle of images may stay similar or even shrink. If size matters, use the Standard 2x setting and run the result through Compress PDF afterwards.
Which languages does it recognise?
English only. The English trained data is the single language model bundled with this site so that nothing has to be fetched from a third-party CDN. Pointing it at another script does not raise an error, but it does not produce a usable layer either: the invisible text can only hold characters in the PDF WinAnsi set (ASCII, Latin-1 and the usual typographic extras such as € and ™), so Chinese, Japanese, Greek, Cyrillic, Arabic or Devanagari text ends up as a few stray Latin characters or nothing at all. Whatever the engine thought it saw is still shown in full in the recognised-text panel. Accented Latin text in French, German or Spanish often comes out mostly right, but the model is not trained for it.
How accurate is it?
On a clean, flat, well-lit 300 DPI scan of ordinary printed type, very good. On a phone photo of a page shot at an angle in poor light, poor. OCR accuracy is dominated by the input, not by the engine — sharpness, contrast, straightness and text size in the frame matter far more than any setting. Words the engine scores below 30 out of 100 are left out of the text layer rather than added as noise, and the result panel reports the average score of the words that did go in. Because that average only covers the words that were placed, it stays high even when the engine read almost nothing, so the word count is checked as well: a run that recognised nothing, or fewer than a handful of words per page, is reported as such instead of as a success. Small print is the one case where the resolution setting really moves the needle: 5-point type that reads at 70% confidence at 2x can read at 94% at 3x.
My scan is sideways or upside down.
Turn it the right way up first, with Rotate PDF. This tool reads the page exactly as it is drawn and does not detect or correct orientation — there is no page-orientation model in the English-only build. A page lying on its side does not fail: the engine reads the marks column by column and returns confident-looking rubbish, which is worse than a failure because it goes into the text layer. The one signal you get is the confidence figure, and it is a reliable one: an upright page of printed type comes back in the nineties, and even a badly blurred one still scores in the low eighties, while a sideways page lands in the sixties. Below 75% the page says so in an orange warning and tells you to rotate and retry.
Does it read handwriting, or reproduce tables?
No to both. Tesseract is trained on printed type; cursive comes back as confident-looking nonsense. Table structure is not reconstructed either — the words inside a table land in roughly the right places on the page, but there is no table object, so pulling a grid out of the result is not something this produces. For tabular data from a PDF that already has real text, PDF to Excel is the right tool.
My PDF already has selectable text. Should I run it through this?
No, and you do not have to check by hand: the moment you drop a file in, the first three pages are scanned for existing text, and if there is any real amount of it an orange warning appears above the button before you run anything. OCR on such a file would only replace crisp vector text with a picture of it plus a guessed layer — strictly worse on every axis, and several times the size. Use PDF to Text to pull the words out instead. The button is not disabled, because there is one case where re-running is right: a file whose existing text layer is itself a bad OCR job you want to redo. This tool exists for the other case, where a document is nothing but scanned images.
Why is it so slow?
Recognition is a neural model running in WebAssembly on your own CPU, roughly a few seconds per page depending on how dense the page is and which resolution you picked. Nothing is being uploaded to a server farm, which is the trade: privacy and no upload limit in exchange for your laptop doing the work. A long document is best left running in a foreground tab — background tabs get throttled by the browser. If you started the wrong file, Stop ends the run and gives you the controls back.
Can I change the resolution after a run?
Yes. Change the setting and press Run OCR again — the page tells you when the result on screen was produced at a different resolution from the one currently selected, and the download keeps giving you the last result actually produced until you re-run. Nothing is re-uploaded or re-read from disk; your file is still loaded.
Can I get the plain text as well?
Yes. Everything the engine read is shown in the panel under the progress bar with a copy button, so you can paste the raw text straight into a document without opening the PDF at all. If the browser blocks clipboard access the button says so instead of pretending it worked — select the text and press Ctrl+C or Cmd+C. If the engine read nothing at all, the panel says so and the copy button is greyed out rather than silently copying an empty clipboard.
It failed part way through.
The message on screen says which of these it was. A PDF that needs a password to open cannot be read at all — run Unlock PDF first; a file that merely restricts printing or editing opens here normally. A blocked engine or language download is reported as an engine problem, not as a fault in your PDF. Very large pages are rendered below your chosen resolution automatically so the browser's canvas limit is never hit, and the result panel tells you when that happened; if the tab still runs out of memory on a long document, drop to 2x or cut the file into parts with Split PDF. Nothing is ever stuck: Stop ends a run in progress and hands the controls straight back.
Is any of this uploaded?
No. The pdf.js renderer, the Tesseract WebAssembly core, the English trained data and the pdf-lib writer are all served from this site and run inside this browser tab. Your document is read with the File API, held in memory, and written straight back to your downloads folder as searchable-yourfile.pdf.