Image to Text — Free OCR to Extract Text from a Photo (In-Browser)

OCR accuracy is almost entirely about input quality

A printed document photographed from across a desk fails where a close crop taken from directly overhead succeeds. OCR does not see what you see — it sees pixels, and it needs enough of them per character to tell one letter from another. A useful rule of thumb: if you could not comfortably read the text yourself at the size it occupies in the image, the engine will not either. Around 300 DPI for a scan is reliably good; 200 DPI is workable but noisier; a phone photo taken from several feet away is hopeless regardless of how many megapixels the camera has, because the text still occupies too few of them.

Four factors decide whether OCR will work

• Resolution. More pixels per character is the single biggest lever. Photograph the page close enough that the text fills the frame. Do not zoom in afterwards — enlarging a small image only enlarges the blur.
• Contrast. Black text on white is easy; faded pencil on yellowed paper is hard. The optional "Straighten & clean scan first" setting deskews the image and boosts contrast before the engine sees it, and it is worth trying on any scan that fails the first time.
• Lighting. Even illumination with no glare or hard shadow. A desk lamp casts a sharp shadow across the page; diffused daylight or overhead room light works better. Watch for your own shadow when shooting from above.
• Angle. Square-on, not slanted. Text that runs diagonally across the frame confuses the line-detection stage before character recognition even begins.

What reliably fails, and why

Handwriting is out — the engine is trained on printed type and will produce nonsense from cursive. Decorative and script fonts are misread for the same reason. Very small print becomes unreliable unless you raise the resolution to compensate. Coloured backgrounds and watermarks crossing the text cut the contrast the engine depends on.

Two layout problems are worth calling out separately, because the words come through correctly and the structure does not. Dense multi-column layouts can be read in the wrong order, interleaving text from adjacent columns. Tables are the worst case: the individual cell contents are usually recognised fine, but column structure is not preserved, so a tidy three-column table arrives as a flat run of values with no indication of which column each belonged to. If your source is really a spreadsheet or a PDF with a text layer, extracting from that will always beat OCR.

Expect to proofread

OCR produces a transcription, not a formatted document. The characteristic failure is numeric and quiet: 0 read as O, 1 read as l, or a digit dropped from a longer string. Nothing looks wrong on the page — a misread invoice total or reference number reads as perfectly plausible. Always check the output before using it anywhere the exact wording or figures matter.

What the tool actually runs

Recognition uses Tesseract, running entirely in your browser: your image is never uploaded. The one thing fetched from the network is the language model, downloaded once on first use and cached by the browser afterwards. Files up to 100 MB are accepted, and images are scaled to at most 2600 pixels on their longest side before recognition, which is ample for accuracy and keeps processing quick. Any image format your browser can decode is accepted, and PDFs work too.

Thirteen languages are available: English, Spanish, French, German, Portuguese, Italian, Dutch, Russian, Arabic, Hindi, Chinese (Simplified), Japanese and Korean. Pick the right one before running — the model is language-specific, and English is the default.

Extracting text from a picture is the same problem as extracting it from a scanned document, where the pages are images rather than text. For that case, PDF OCR is the tool.