OCR Explained: How to Turn a Scanned Document or Photo Into Editable Text

You have a photo of a whiteboard, a scanned receipt, or a screenshot of a spec you can't copy from. The text is right there, just trapped inside pixels. OCR is the tool that turns those pixels back into words you can search, copy, and edit.

What most people don't realize is how much the accuracy depends on the source image, not the OCR engine. A crisp scan of a printed document hits 99% in any modern OCR. A phone photo of a handwritten note in dim light hits maybe 60%. The tool is the same in both cases — the input isn't. Here's what's actually happening, and how to get the best results.

How OCR actually works

Modern OCR is a two-stage pipeline. First, a text-detection model finds regions of the image that look like text — rectangles of the right size and orientation with the right density of dark-on-light pixels. Second, a text-recognition model looks at each region and predicts the actual characters, one line at a time.

The browser tool at EasyFileMagic OCR uses Tesseract, an open-source engine that Google maintained and released years ago. It runs entirely in your browser via WebAssembly — no server upload, no queue. First run downloads the language data (English is about 10 MB); after that it's instant.

Both stages are AI models. Both make mistakes. The interesting question is what makes them mistake-prone.

What accuracy to actually expect

Rough numbers from my own use:

• Clean scanned document, 300 DPI: 99%+ on printed text, occasional errors on complex layouts (tables, multi-column).
• Phone photo of a document in good light, held flat: 95–98%.
• Phone photo at an angle or in dim light: 80–95%, with occasional whole-line misreads.
• Screenshot of a UI at native resolution: 98–100% (best case — text is anti-aliased and pixel-perfect).
• Handwriting: 40–80%, wildly variable by handwriting style. Cursive is worse than block letters. English is much better supported than any other script.

In practical terms: for a scanned invoice, expect to skim the result and fix maybe two words. For a phone photo of a receipt, expect to fix five to ten. For a photo of your notebook, expect to more or less rewrite everything but at least the structure is captured.

How to get much better results without switching tools

These are ranked by how much impact each one has.

Resolution and sharpness

The single biggest factor. Text needs to be at least 20 pixels tall in the source image for reliable recognition. If you're scanning, use 300 DPI minimum — 400 for small print. If you're photographing, get close, tap to focus, and hold the phone steady. A blurry photo of a document destroys OCR accuracy no matter how good the engine is.

Lighting and contrast

Even, diffuse light beats harsh directional light every time. A window on an overcast day is the ideal desk-photo setup. Harsh overhead light produces glare spots and deep shadows, and both eat characters. If contrast is low (yellowed paper, faint print), converting the image to high-contrast black-and-white before OCR helps a lot.

Angle and rotation

OCR engines handle small tilts (up to about 10°) automatically. Beyond that, straighten the image first — many phone camera apps have a document-scan mode that flattens perspective. A perfectly-flat page with straight lines works dramatically better than a tilted one.

Cropping

Crop tight to just the text you care about. Big empty margins, decorative headers, or table borders can confuse the text-detection stage into missing lines or merging separate paragraphs.

OCR-ing a multi-page PDF

Scanned PDFs are basically photographs wrapped in PDF form — searching for a word inside them returns nothing, because the document has no text data, just images of text. The OCR tool handles this: it rasterizes each page, runs OCR on it, and gives you the extracted text as a downloadable .txt file (or copy-to-clipboard for a single page).

From there, if you want a searchable PDF rather than plain text, you can rebuild one using Text / Markdown to PDF. You lose the visual layout, but you gain a small text-based PDF that's fully searchable, works with screen readers, and is a fraction of the size of the original scan.

A note on languages other than English

Tesseract supports over 100 languages, but the accuracy varies enormously. English, German, French, Spanish, and other Latin-script languages with lots of training data are excellent. Chinese, Japanese, Korean are good with the appropriate language pack. Right-to-left scripts (Arabic, Hebrew) work but are more error-prone. Rare scripts and historic writing systems are a coin flip.

Where OCR still can't help you

Two cases you'll run into:

• Handwritten cursive. Modern OCR is a lot better than it used to be, but cursive handwriting remains a hard problem. Specialised handwriting recognition (HWR) tools do slightly better, but nothing at consumer scale is reliable enough to trust unread.
• Text embedded in complex graphics. A logo with the company name curved around a shape, a poster with text over a busy photograph, ASCII art. OCR is optimised for rectangular text regions on plain backgrounds. Anything else struggles.

For those cases, the honest answer is to retype the text. Sometimes that's what's easiest.

A realistic end-to-end workflow

You get a scanned PDF of a 20-page contract. You want to find the clause about termination but the PDF isn't searchable.

1. Open OCR, drop the PDF in, wait for it to process each page.
2. Copy the extracted text into a text editor and search for "terminate" or "termination."
3. Jump back to the corresponding page in the original PDF to read the actual clause with its full formatting.

This is the pattern for basically every OCR job: the extracted text is a searchable index into the original, not a replacement for it.