Extract editable text from images and scanned PDFs — JPG, PNG, WebP or PDF — right in your browser. No upload, no sign-up, no file-size limit, completely private.
Drop images or a PDF here or browse
JPG · PNG · WebP · PDF — or paste a screenshot with Ctrl/⌘ + V
Clean up automatically upscales the image, converts it to black on white with a threshold computed locally so an uneven lamp or a page shadow does not black out half the page, flips white-on-dark text the right way round, and adds a white margin. This is where most OCR accuracy is won or lost, long before the model sees anything. Switch to Gentle for a clean digital PDF, where thresholding can only throw information away.
🔒 The OCR engine runs entirely on your device — your images and PDFs are never uploaded.
Most OCR sites upload your files. This one keeps everything on your device — safe for IDs, receipts and contracts.
Recognize printed text across Latin, Cyrillic, Arabic, Devanagari and CJK scripts — English through to Chinese, Arabic, Hindi, Japanese and Korean.
Turn photos, screenshots and multi-page scanned PDFs into editable, copy-paste-ready text.
The engine is Tesseract, compiled to WebAssembly and running inside a worker thread in your browser. It is configured to use the LSTM neural network model rather than the older pattern-matching engine — the same model that ships with desktop Tesseract, doing the same work, just executing on your machine instead of someone's server. That is what makes the privacy claim structural rather than a promise: there is no endpoint to send an ID card or a contract to.
Two things are fetched over the network, and it is worth being precise about them. The first is the engine itself. The second is the language model for whichever language you select, which is downloaded on first use and then cached by the browser, so the first run of a new language is noticeably slower than every run after it. Neither transfer includes your file.
PDFs take an extra step. Each page is rendered to a canvas with pdf.js at triple scale — about 216 pixels per inch, close to the 300 the model was trained on — and that image is what gets recognised. Multiple files are processed in order and their text is concatenated, with a header line naming each source file when there is more than one. The confidence percentage beside the result is Tesseract's own average certainty across everything it read.
| Input | Expect | Why |
|---|---|---|
| Screenshot of on-screen text | Near-perfect | Clean, aligned, high contrast, rendered at native resolution. |
| Flatbed scan of a printed page | Very good | Straight, evenly lit, standard fonts. |
| Phone photo of a document | Good if careful | Perspective, shadow and blur all cost accuracy. Shoot square-on in even light. |
| Receipt or invoice | Text yes, layout no | Output is a linear stream, so columns of item and price interleave rather than staying aligned. |
| Multi-column page or newspaper | Mixed | Column detection is imperfect; lines from adjacent columns can be merged. |
| Handwriting | Poor | Tesseract is trained on printed type. Cursive in particular is not what this model does. |
| Stylised, decorative or very low-contrast type | Poor | Unusual letterforms fall outside the training data. |
Resolution is the most common cause of bad results, so the tool now measures it rather than guessing. Before recognition it estimates how tall a line of text actually is — by thresholding a thumbnail locally and looking at the runs of rows that contain ink — and scales the image so a line lands near 34 pixels, which is where the model is comfortable. Scaling by the image's dimensions instead is a trap: a 700×200 screenshot of a terminal has perfectly legible type, and blowing it up seven times turns crisp glyphs into porridge. Measured, that mistake took a dark-mode screenshot from 86% confidence to zero.
Uneven lighting is the second. A photograph of a page is brighter near the window and shadowed near the spine, and one global black-or-white cut-off turns the dark half solid black. The threshold here is computed per pixel from the local mean and standard deviation (Sauvola), so it follows the light across the page. On a test photograph with a strong gradient, 16-pixel serif text and sensor noise, that moved character accuracy from 82.7% to 100% and Tesseract's own confidence from 68% to 95%.
Both steps are skipped when they would do harm. An image that is already essentially two-tone — a screenshot, a clean digital render — is left alone apart from a contrast stretch, because thresholding something crisp can only lose thin strokes. Light text on a dark background is flipped the right way round, since the model expects ink on paper. What none of this can fix is information that was never captured: a distant photograph where the body text is a few pixels tall has nothing to recover.
Long PDFs are a memory problem. Every page is rendered before recognition begins, and each A4 page at this scale occupies roughly 8 MB as a canvas — so a hundred-page document asks for something close to a gigabyte before a single word is read. On a phone or a modest laptop that will fail. Split long documents first with the PDF splitter and run them in batches of ten or twenty pages.
One language at a time. The selector applies to everything in the queue, so a document mixing scripts will only be read well in the language you chose. Picking the wrong one does not degrade gracefully — it produces confident nonsense, which is worse than an obvious failure.
Confidence is self-reported. The percentage is the engine's estimate of its own reliability. Below about 55% it is flagged as low and you should treat the output as a rough draft, but a high figure is not proof of correctness either. Errors cluster predictably around characters that look alike — 0 and O, 1 and l and I, 5 and S, 8 and B — which is exactly where a misread does the most damage in an account number or an invoice total. Proofread digits.
Layout and formatting are discarded. You get plain text: no bold, no headings, no tables, no reading order guarantees on complex pages. And HEIC photos from an iPhone will not decode outside Apple platforms — convert them with the HEIC converter first.
The single biggest saving is knowing when not to use OCR at all. A PDF produced by exporting from a word processor already contains real text; running recognition on a picture of that text throws away perfect data and hands back an approximation. Try PDF to text first — if it returns the content, you are done, instantly and with no errors. Only reach for OCR when the PDF is a scan, meaning you cannot select the text in a PDF viewer.
When you do photograph a document, the fundamentals do more than any setting: fill the frame with the page, shoot square-on rather than at an angle, use diffuse light with no shadow falling across the text, and hold still enough to avoid motion blur. Crop away everything that is not text before running it. If a page is skewed, straighten it first — the cropper handles rotation, and even a few degrees of skew measurably hurts line detection.
The result lands in an editable box, which is deliberate: OCR output is a starting point. Fix the obvious errors there before copying, since it is far quicker than doing it after pasting into a document. You can also paste an image straight from the clipboard onto this page rather than saving it first — useful for screenshots. Once the text is clean, the word counter gives you a quick sanity check on length, and the wider set is on the text tools page.
No — the OCR runs entirely in your browser, so your images and PDFs never leave your device. The recognition engine and the language model are downloaded from a CDN the first time you use them, which is why a connection is needed to start, but your file is never part of any request.
Nineteen, spanning Latin, Cyrillic, Arabic, Devanagari and CJK scripts: English, Spanish, French, German, Italian, Portuguese, Dutch, Russian, Ukrainian, Polish, Turkish, Arabic, Hindi, Japanese, Korean, Simplified and Traditional Chinese, Vietnamese and Indonesian. Choose your document's language before running — the selection applies to every file in the queue, and the wrong choice produces confident nonsense rather than an obvious failure.
Yes — every page is rendered and recognized, then combined into one editable block of text. Long documents are the practical limit: pages are rendered before recognition starts and each one costs around 8 MB of memory, so split anything over about twenty pages and run it in batches.
OCR is strongest on clear printed text. Handwriting, blurry photos and complex layouts are harder. A sharp image and the right language help, and the output is fully editable. Check digits especially — misreads cluster on characters that look alike, such as 0 and O, 1 and l, 5 and S, and 8 and B.
Three things, all decided by measuring your image rather than by a fixed recipe. It works out how tall a line of text actually is and scales the image so a line lands near 34 pixels — the size the model was trained on. It computes the black-or-white threshold locally, per pixel, so a lighting gradient across a photographed page does not black out the shadowed half. And it adds a white margin, because Tesseract treats the image edge as a hard boundary and clips characters that touch it. On a test photo with a strong gradient and small serif text this moved character accuracy from 82.7% to 100%. It also knows when to do nothing: an image that is already two-tone — a screenshot, a clean render — only gets a contrast stretch, and light-on-dark text is flipped rather than mangled.
It tells the engine what kind of picture it is looking at. The default assumes a page and tries to find columns, which is right for a document and actively wrong for a receipt, a road sign or a single line — there it invents a layout and then reads it in the invented order. If a result comes back scrambled rather than misspelled, the layout is usually the thing to change: try One block of text for a photo of a paragraph or a receipt, A single line for a caption, or Scattered text for signs and labels.
No daily caps, no paywall and no fixed size limit — you're only bounded by your device's memory.
No. If you can select and copy text in a PDF viewer, the file contains real text and OCR would only replace it with an approximation. Use PDF to text instead, which reads it directly — faster, and with no recognition errors at all. Save OCR for scans and photographs, where there is no text layer to extract.