The text in an image is locked: you can read it, but you can't select it, search it, or paste it anywhere. OCR (optical character recognition) is the unlock — it examines the pixels and reconstructs the words as editable text. Whether it's a screenshot of an error message, a photo of a whiteboard, a receipt for expenses, or a street sign in a language you're learning, here's what actually determines whether you get clean text or garbled noise, and how to run the whole thing without uploading a thing.
An OCR engine does three passes. First it segments the image: finds regions that look like text, splits them into lines, then into words, then into candidate characters. Then it classifies each candidate — comparing the shape against a trained model that has seen millions of examples. Finally it applies language context: knowing the surrounding letters and real words of the language, which is how an engine decides that a smudge is more likely an "e" than a "c". That last pass is why specifying the right language matters, and why OCR on gibberish strings (serial numbers, license plates) misreads more than prose does.
The engine behind most free tools, including the one linked below, is Tesseract — developed at HP in the 1980s, open-sourced, and now compiled to WebAssembly so it runs inside a browser tab. Your image gets decoded to pixels by the browser, and the pixels are processed on your own machine.
Character height. Text needs roughly 20 pixels of x-height — the height of a lowercase "x" — for reliable segmentation. Below that, adjacent letters merge into blobs; above it, more pixels add processing time without adding accuracy. Quick arithmetic: a 1920×1080 screenshot of a chat window has x-heights of 15-25 pixels and OCRs beautifully. A photo where the whole page fills the frame does too. Crop out one sentence from that same photo and zoom in, and you may drop below the threshold even though the image "looks big."
| Source | Typical pixels | What to expect |
|---|---|---|
| Screenshots | 1200×900 ≈ 1.1M | Near-perfect — flat, sharp, straight |
| 300 DPI document scans | 2550×3300 ≈ 8.4M | Excellent; proofread the digits |
| Phone photo, page fills frame | 4032×3024 ≈ 12.2M | Good, if straight and evenly lit |
| Small crops / distant signs | varies | Often below the character-size threshold |
Cameras break the assumptions scanners keep. The usual four, with fixes:
If an image still misreads after a straight re-shoot, run it with the higher-accuracy model (tools usually offer a fast/standard choice — standard English is 10.4 MB versus 1.9 MB fast, downloaded once and cached). On genuinely difficult images the difference is real.
The one that matches the text, because the language model is doing the disambiguation pass. Over 100 languages have trained models. Sizes vary a lot — worth knowing when you're on mobile data:
| Language | Fast model | Standard model |
|---|---|---|
| English | 1.9 MB | 10.4 MB |
| Spanish | 1.1 MB | 8.0 MB |
| German | 0.8 MB | 6.8 MB |
| Russian | 1.5 MB | 8.2 MB |
| Chinese (Simplified) | 1.6 MB | 19.2 MB |
| Japanese | 1.5 MB | 15.4 MB |
Mixed-language images (an English receipt with a Japanese restaurant name) work better if the tool lets you load both languages — you pay both downloads, and both models vote during classification.
Three cases that look identical from the outside:
The test takes two seconds and saves you from OCR-ing something that never needed it.
Depends entirely on where the processing happens. Server-side converters ship your image — potentially a receipt with card numbers, a document with personal data — to someone else's computer, and you're trusting their storage and retention. Browser-side tools that compile the engine to WebAssembly keep everything local: the only network traffic is the engine and language model downloading from a CDN, and after that, nothing. Check a tool's claims in the network tab while it runs — a local run shows zero image uploads.
100+ languages, fast and standard models, optional contrast preprocessing — runs entirely in your browser.
Open Image to Text OCRTwo honest limits. Handwriting: engines trained on print only partly decode neat block capitals and mostly fail on cursive — specialized handwriting models exist but they're a different product category. Mathematical notation: formulas OCR poorly because the two-dimensional layout (superscripts, fractions, radicals) doesn't survive line segmentation. For both, a human still beats the machine, and knowing that before you spend twenty minutes trying settings is half the value.