Tesseract hit 53% word error at 6px text. Claude vision hit 0%
Compressing a scan to a twentieth of its file size changed nothing for either engine. Shrinking the text from 8 pixels tall to 6 destroyed classical OCR completely and did not touch AI vision, including on serial numbers that cannot be guessed.
Every “best OCR tool” guide ranks products out of ten. None of them tells you the thing you actually need: how bad can the image get before it stops working.
So I rendered a document at known text, degraded it along two axes with exact ground truth preserved, and measured word error rate for a classical engine and an AI one.
Compression does not matter. At all.
| JPEG quality | File size | tesseract | Claude vision |
|---|---|---|---|
| original PNG | 37,656 B | 0.0% | 0.0% |
| 25 | 26,960 B | 0.0% | 0.0% |
| 5 | 12,264 B | 0.0% | 0.0% |
Quality 5 is aggressive enough to leave visible blocking artifacts and cuts the file to a third. Neither engine lost a single word.
If you are compressing scans to save space, or worrying that WhatsApp mangled a document photo, compression is not your problem.
Text height is the only thing that matters
Same document, scaled down and back up so the information is genuinely lost. Text height is the actual glyph height in pixels.
| Scale | Text height | tesseract | Claude vision |
|---|---|---|---|
| 100% | 28px | 0.0% | 0.0% |
| 40% | 11px | 0.0% | 0.0% |
| 30% | 8px | 0.0% | 0.0% |
| 25% | 7px | 3.7% | 0.0% |
| 20% | 6px | 42.6% | 0.0% |
Tesseract is flawless down to 8 pixels and falls off a cliff at 6. Not a gradual slide: 0.0%, then 3.7%, then 42.6%. Two pixels of glyph height is the difference between a perfect transcript and a useless one.
Claude vision did not notice the cliff.
The control that makes this claim survivable
At 6 pixels the text is barely legible to me. A language model transcribing ordinary English at that size could plausibly be guessing rather than reading, and would score perfectly for the wrong reason.
So I repeated the whole ladder with content that cannot be guessed: serial numbers, torque values, bin numbers.
Serial XKD-9071-BB replaced serial XKD-4438-PA today. Torque set to 62.7 Nm, tolerance plus or minus 0.35 Nm.
| Scale | Text height | tesseract | Claude vision |
|---|---|---|---|
| 100% | 28px | 0.0% | 0.0% |
| 30% | 8px | 6.7% | 0.0% |
| 25% | 7px | 13.3% | 0.0% |
| 20% | 6px | 53.3% | 0.0% |
At 6 pixels Claude returned XKD-9071-BB and XKD-4438-PA and 62.7 correctly. There is no way to infer those from context, so it is reading the pixels.
The unguessable text also exposes what tesseract is missing
Look at the two tables together. On ordinary prose tesseract was perfect at 8px. On serial numbers at the same 8px it made errors, 6.7%. At 7px it went from 3.7% on prose to 13.3% on serials.
Classical OCR degrades faster on content it cannot pattern-match, because it has no language model to lean on when the shapes get ambiguous. That is worth knowing precisely because the things you most need read correctly from a bad scan, invoice numbers, part codes, amounts, are exactly the content with no linguistic redundancy to rescue it.
What each is actually for
| tesseract | Claude vision | |
|---|---|---|
| Clean document | perfect | perfect |
| 6px text | unusable | perfect |
| Serial numbers on a bad scan | worst case | perfect |
| Speed | under 1 second | 9 to 15 seconds |
| Cost | free, local, offline | a model call per page |
On a clean scan they are indistinguishable, and tesseract is more than ten times faster and needs no network. The gap only opens when the image is bad, and then it opens completely.
What this does not establish
Rendered text, not photographs. Every image here started as cleanly rendered type and was degraded synthetically. A real phone photo adds lighting gradients, curvature, perspective skew and focus falloff, none of which is tested. I would expect the ranking to hold and the thresholds to move.
One font, one size, one language, one page. Two documents of 45 and 54 words. Nothing here is a general accuracy rate for either engine.
Claude vision did not fail anywhere I tested, which means I found tesseract’s cliff and not Claude’s. Its limit is below 6 pixels, and I do not know where.
Word error rate ignores case and punctuation, so both engines are scored generously and only real word mistakes count.
Method
Two documents rendered at 30pt with exact known text, degraded along two axes: JPEG quality 90 down to 5, and downscale to 40%, 30%, 25% and 20% followed by upscale back to original dimensions so the information is genuinely destroyed rather than merely displayed smaller. Glyph height measured directly from a trimmed render. Word error rate is Levenshtein distance over normalised word sequences, control-tested against six hand-checked cases including substitution, deletion, insertion and punctuation-only differences before any engine was scored. tesseract 5.5.2 locally; Claude vision via Claude Code 2.1.226 headless reading the image file. Degradation was confirmed to have actually applied by file size and by visual inspection of the worst case.