How accurate is OCR, really?

Fifteen images, one known answer for each, scored character by character. What clean type costs, where every engine falls apart, and the settings that actually move the number.

The short answer

On clean printed text, OCR is effectively perfect. Ten of our fifteen test images came back with not one wrong character, including a page compressed to JPEG quality 10, a blurred page and a page in mid grey on white. Across all fifteen the mean character error rate was 2.03%.

That average is misleading in a useful way. OCR does not degrade gently; it is either right or it falls over. And when it falls over it is usually not because it failed to recognise the letters. It is because it misread the shape of the page.

How this was measured

Every image was rendered from HTML by headless Chrome, so the correct answer is the exact string that went in rather than somebody's transcription of it. That is the part that makes a character-level score meaningful.

The two scores exist because they fail differently, and the difference is the most useful thing in this article. Character error rate punishes a reordered page as harshly as a misread word. Word recall ignores order entirely. When the first number is bad and the second is good, the engine read your characters correctly and put them in the wrong sequence, which is a completely different problem with a completely different fix.

The results

Lower is better for error rate, higher is better for recall. This is the browser engine in its shipped configuration.

What the failures have in common

Look at the receipt. It scores 18.34% on characters and 74.4% on recall, and the gap is the whole story: three quarters of the words came back correctly and the engine put the price column somewhere else. Nothing about the recognition failed. The page structure did.

The same is true of the code block, where indentation is thrown away, and of the table, where the cells arrive in a defensible but different order. Of the five imperfect rows, four are layout and one is genuinely small type.

Resolution beats quality, and it is not close

We degraded one page five ways and read each. This is the single most actionable result here, because it says which property of a photograph is worth caring about.

Heavy compression artefacts, visible blur and a halving of the pixels each cost nothing at all. Quartering the pixels destroyed the page. A recogniser trained on type around 30 pixels tall is extremely tolerant of ugly and almost completely intolerant of small.

So the advice usually given, use a high quality scan, is aiming at the wrong thing. Get closer, or scan at a higher DPI. A grainy photo of large text will beat a pristine photo of small text every time.

What upscaling recovers, and what it costs

That 96.07% is recoverable. Doubling the image before reading it took the same page to 3.54%. But upscaling is not free, and the failure is instructive:

Two images of almost the same width, and doubling helps one enormously and ruins the other. The 419px screenshot holds 16px type; the 611px table holds 32px type. Image width is a bad proxy for text height, and any tool that upscales based on file dimensions will damage somebody's table.

The fix is to read once, measure the height of the word boxes that come back, and only then decide whether to try again bigger. That is what the tool beside this article does.

Confidence scores work, if anyone shows them to you

Every mainstream engine returns a per-word confidence and almost no consumer tool displays it. We checked whether it deserves to be shown by taking all 1,214 words from the benchmark and asking, for each confidence band, how often the word was actually wrong.

The cliff is at 90, and it is a big one. A word scored in the eighties is still wrong about a third of the time, which is why the common threshold of 70 is too generous to be useful.

Flagging everything under 90 marks 62 words, about 5% of the text, and catches 27 of the 38 words that were genuinely wrong. Flagging under 70 marks 19 words and catches 12. The looser line marks less and misses more, so it loses on both counts.

The practical consequence: you do not have to proofread an OCR result against the original. You have to check about one word in twenty, and a tool that marks them turns a ten-minute job into a thirty-second one.

Where a browser engine loses to a cloud one

We ran the same files through imagetotext.info, the converter ranking first for "image to text", which posts your file to its server. It is better, and it is worth saying so plainly.

On clean pages the two are identical. On the awkward ones the cloud engine wins outright, because it is a much larger model running on hardware you are not paying for directly. If the last two percent matters more than anything else, that is the honest recommendation.

What it costs is a copy of the document. That is a real trade and it should be made deliberately, which is hard when the page tells you it is not happening. Three of the six converters we tested display a privacy promise directly above a form that uploads your file, and one of them publishes "runs 100% in your browser, your images are never uploaded to any server" as structured data for search engines to read, on a page that posts your file and then polls the server for it by name.

The three fixes that actually work

In order of how much they moved the number in this benchmark.

1. Tell the engine the page is one block

   The largest single rescue available, and the one almost no tool exposes. It took the tilted page from 100% error to 0.00% and the receipt from 18.34% to 1.31%. Reach for it whenever a result comes back empty, jumbled, or in the wrong order.

2. Give it more pixels, not a better camera

   Upscaling recovered a ruined page from 96.07% to 3.54%. Getting closer in the first place is better still, because interpolation cannot add detail that was never captured. Aim for text at least 20 pixels tall.

3. Flatten it to black and white when the page is odd

   Worth trying on coloured text, an uneven photograph or a dark-mode screenshot. It took the tilted page from 100% to 9.82% on its own. On an ordinary black-on-white page it changes nothing or makes it marginally worse, so it is not something to leave on.

Deskewing, the fix everyone reaches for on a tilted page, helped least of anything we tried. Our estimator found the three degree angle correctly and the reading barely improved, because the problem was never the angle itself. It was what the angle did to the engine's idea of where the lines were.

How long it takes

Reading speed is rarely the deciding factor, but the numbers are small enough to be worth knowing. On the machine above, with the engine already loaded, the fifteen images took 5.2 seconds in total: a median of 0.32 seconds each, from 0.10 to 0.55.

A local engine pays for that in download instead. Roughly 3.4 MB compressed, once, then cached, which is the engine plus one language model. A cloud converter downloads nothing and uploads your file every time, so on a slow connection with a big photograph it can easily be the slower of the two.