How to Extract Text From an Image Without Uploading It

Almost everything written about OCR is about the engine, and the engine is rarely the problem. I built the image to text tool on this site and then spent a day feeding it deliberately awkward files, and the result was not a story about accuracy percentages. It was a short list of things that decide whether a page reads at all: how many pixels tall the letters are, which way up the pixels are stored, whether the file has characters in it or only a picture of characters, and how you find out that it went wrong.

The numbers below come from running the tool, not from its description. Two of them contradicted what I expected, and one of those contradictions made me delete a feature.

Rule one: the letters need about 30 pixels of height

OCR does not read words, it matches shapes, and a shape needs pixels to exist in. Below roughly 30 pixels of capital height the letterforms stop being distinguishable and the engine starts guessing at plausible words. That is why a screenshot of a paragraph usually reads perfectly and a photo of a whole A4 page taken from a metre away usually does not — the page fits in the frame, so each letter is eight pixels tall.

The tool measures this and scales the image up when it needs to: anything under 1,000 pixels on the long edge is enlarged, up to 2,400. A 400x300 crop of a receipt is a 3x upscale before recognition, and that is the difference between noise and a number you can copy.

The ceiling matters too. A 6,000-pixel photo is four times the work for no gain, so it is scaled down to 4,000. The hard limit is 40 megapixels — a decoded-pixel count, not a file size — because past that a browser tab runs out of canvas memory rather than producing a worse result. A 30 MB JPEG of a wall is fine; an 80 MP PNG is refused, and the message says which number it hit.

Rule two: a phone photo is stored sideways and looks fine

This is the one that costs people their afternoon, because nothing about the failure is visible. A phone held upright stores the photo as landscape pixels plus a tag in the EXIF header saying "rotate 90 degrees to display". Every browser and every image viewer applies that tag, so the photo looks upright on screen while the pixels underneath are on their side.

Feed those pixels to an OCR engine and it reads sideways text, which is not text. It does not error — it returns confident nonsense.

I know exactly how much this costs, because I got the rotation direction wrong once. The same page, rotated 180 degrees out of phase, came back at 25% confidence with every word on the "check these" list, and the text was unreadable garbage. With the rotation applied correctly it read at 95%. Same file, same engine, same second — the only variable was which way up the pixels were.

The tool reads the orientation tag out of the JPEG header itself and rotates the pixels before recognition. It then checks the decoded size against the size stored in the file, because asking a browser not to apply EXIF rotation is a request it may or may not honour, and rotating twice is as wrong as not rotating at all. A test file stored sideways with the tag set to 6 — 42,821 bytes, text lying on its side in the bytes — reads back as the same 17 words at 95% as the upright original.

If you are checking a competitor: open the photo in an image viewer, confirm it looks right, and then ask whether the tool actually read the tag or simply got lucky with the browser default. The two are indistinguishable from the output until you hit a file where they disagree.

Rule three: a scan has no text in it, and that is not the tool's fault

A PDF can contain characters with positions, or it can contain a picture of a page. A scanner produces the second. Every PDF-to-text tool that reads the text layer returns an empty file for a scan, and most of them do it silently — which is why "the converter gave me a blank .txt" is such a common complaint.

OCR is the answer, and it works because it never looks for characters: it looks at pixels. A one-page image-only PDF, 33,695 bytes with no text layer at all, came back as 1 page, 17 words, 95% confidence in 414 ms. The page is rendered at 144 dpi and read as an image, page by page, with the page count on the result line so a 40-page report tells you where it is rather than leaving you with a spinner.

One hundred pages is the ceiling, and it is stated before you start rather than discovered at page 60. At roughly a second a page in a browser tab, that is a minute and a half of work — enough that the tool waits for you to press the button rather than starting on drop.

Rule four: know which words it guessed at

An OCR result is not right or wrong, it is a set of words with scores. Every engine computes them; almost no interface shows them. That is the difference between proofreading 900 words and checking five.

The tool reports the page confidence as a badge, and names up to five distinct words that scored below 60. On the cursive test below, that list is the entire value of the run: the text looked fine at a glance and the list pointed straight at the one number that was wrong.

What I got wrong, twice

The lighting fix that did nothing. Phone photos of paper are unevenly lit, and Tesseract thresholds the whole page against one value, so a page that is bright on the left and dim on the right should lose one end of every line. I wrote a pre-filter that subtracts a blurred copy of the image to flatten the gradient, put it behind a "Photo mode" switch, and measured it. On a page whose right-hand side was multiplied down to 40/255 — a hard shadow across the paper — it changed the confidence by zero, 95% both ways. On a milder grey-on-grey page it made things worse: 95% down to 93%.

Tesseract already thresholds each page and runs its own preprocessing, so my divide-by-blur was removing detail it had kept. I deleted the switch. A control that measurably does nothing is worse than no control: it invites you to fiddle, and it implies the tool needs help it does not need.

The handwriting claim that was wrong. I wrote that flowing script reads poorly, because Tesseract was trained on printed type and joined-up writing has no consistent letterforms to match. Then I rendered four lines in a joined-up cursive face at 46 pixels and measured: 86% confidence, with the text almost perfect — one digit wrong, "2026-1042" read as "2026-10422".

So the claim was too strong, and the copy on the tool page now says what was measured instead. A font is not a person: it draws the same letter the same way every time, which is exactly what real handwriting does not do. The honest position is that neat writing often reads, untidy writing often does not, and the confidence figure is the only signal you get before you start proofreading. If you are digitising handwriting, shoot flat and straight, fill the frame, and read the words the tool lists.

Doing it without uploading the document

The reason this matters is not ideology. The pages ranking for "image to text" are mostly upload services, and they say so in their own copy. One of them states, on its front page, "Files are processed over HTTPS and automatically deleted from our servers within one hour" — and, further down the same page, "Pure browser-based". Both sentences are about the same tool. It also caps every file at 10 MB and every batch at ten files.

Another, which is genuinely local, advertises "No registration, no limits" and then "Process up to 10 images to text at once", with accuracy given as "95%+ accuracy on clear images" and nothing about what happens when the image is not clear.

A deletion promise is a statement about a copy that has already left your machine. For a passport, a medical letter or a contract under an NDA, the upload is the part that matters, not the retention window. Here the engine is Tesseract compiled to WebAssembly and it runs in the tab: the image is decoded, rotated, scaled and read locally, and the only network requests are for the engine itself — the worker, the core and the language model, none of which contain any part of your file. After the first run for a language the model is cached by the browser and the page keeps working with the network off.

The short version

Make the letters big enough — the tool does that for you under 1,000 pixels. Let it fix the orientation, which is the failure you cannot see. If the file is a scan, OCR it rather than extracting its text layer, because there is no text layer. Then read the confidence and the five-word check list instead of proofreading everything. A 1,240-pixel-wide page reads at 95% in about 400 milliseconds, model download included, and a sideways phone photo of the same page reads identically once the EXIF tag is honoured.

And none of it requires sending the document anywhere.