Every OCR tool on the internet says it's accurate. Almost none of them show you a single number. We spent a week benchmarking the OCR inside our OCR PDF tool— first against controlled scan conditions, then against a public corpus of real, ugly, 1990s fax-era documents — and we're publishing all of it: the perfect scores, the 70% scores, and the two places where our own benchmark caught our code making things worse.
One thing to know up front: everything below runs entirely in your browser. The scans we tested were processed the same way your documents are — on the device, never uploaded. That's the constraint we work under, and these are the numbers it produces.
How we measured
Our recognition engine is Tesseract (the open-source engine most OCR services build on), compiled to WebAssembly, wrapped in our own rendering, retry, and image-cleanup pipeline. To score it we used word recall: take a document whose true text is known, run OCR, and count what fraction of the true words come back. Two test beds:
- Synthetic conditions — we render a known paragraph into a PDF, rasterize it like a scanner would, then deliberately degrade it: noise, low contrast, blur, tilt, and the uneven lighting of a phone photo. Because we control the truth exactly, these scores are precise.
- Real documents — the public FUNSD dataset: genuine scanned and faxed business forms from the 1990s, with human-labeled ground truth. These are hostile on purpose — real scanner noise, fax compression, stamps, tiny type, and handwriting.
Results: controlled scan conditions
| Condition | Raw engine | Our shipped pipeline |
|---|---|---|
| Clean scan, 300 DPI | 100% | 100% |
| Low quality, 150 DPI | 100% | 100% |
| Tilted 2° | 100% | 100% |
| Heavy speckle noise | 0% | 100% |
| Low contrast (faded copy) | 100% | 100% |
| Blurred photo | 100% | 100% |
| Shaded photo (uneven lighting) | 59.6% | 100% |
| Noise + low contrast combined | 0% | 100% |
| Scanned sideways (90°) | 0% | recovered by rotation retry |
The interesting rows are the rescues. A noisy photocopy or an unevenly lit phone photo reads as garbage — or as half a page — until the image is cleaned up first. Our pipeline despeckles, normalizes contrast, and applies an adaptive black/white threshold before recognition, which is the same class of preprocessing the expensive commercial engines rely on. That's what turns the 0% rows into 100% rows.
Where our own benchmark caught us
We're publishing these because they're the most useful part — and because a benchmark you only quote when it flatters you isn't a benchmark.
Our first cleanup pipeline made blurred photos worse.The initial version used a single global black/white threshold. On a slightly blurred photo it took recognition from 100% down to 0% — it ate the soft edges of every letter. The benchmark caught it before any user saw it, and the fix (deciding black/white locally, against each pixel's neighborhood) is what also cracked the shaded-photo case.
Real fax scans punished cleanup that helped everywhere else.On the real-world corpus, unconditionally preprocessing every page dropped recall from 49.9% to 15.4% — fax output is often already pure black-and-white, and "cleaning" 7-pixel-tall letters just smears them. So the shipped pipeline first checks whether a page actually needs help (mid-tone pixels, detected lighting gradients) and otherwise leaves it alone. After that change, cleanup can rescue a bad page but can no longer hurt a good one — that property is now enforced by the test suite.
Results: real 1990s fax-era forms
| Setup | Word recall (mean, 15 documents) |
|---|---|
| Raw engine on the low-resolution scans | 49.9% |
| Blind preprocessing of every page | 15.4% (yes, worse — see above) |
| Our shipped pipeline (upscaled render + guarded cleanup) | ≈70% |
Honest context for that 70%: the ground truth for these forms includes handwriting, signatures, rubber stamps, and fax-degraded type that no consumer OCR engine reads reliably — 100% is not an achievable score on this material, for us or anyone. The biggest single lever turned out to be resolution: recognizing these scans at double scale lifted recall by 20 points, which our pipeline gets automatically by rendering pages at high resolution before recognition.
We also tested a neural engine — and didn't ship it
The obvious question: would a modern neural OCR model (the PaddleOCR family, run in the browser via ONNX) beat this? We built a prototype and measured it on the same corpus. Result: our simplified neural pipeline scored 41.2% overall — belowour shipped pipeline — but on the single most degraded document, where our engine collapsed to 7.1%, the neural model read 53.3%. So it's parked, with the measurements written down: the interesting future isn't replacing the engine, it's a hybrid that calls the neural model only on pages the fast engine fails. We'd rather ship that when it's measured than claim it now.
What this means if you just want to OCR a document
- Typical scans — clean or mildly rough, straight or tilted: expect essentially everything to come back searchable. This is the overwhelming majority of real usage.
- Phone photos with uneven lighting, noisy photocopies: these used to be the weak spot; the cleanup pipeline now handles them at full accuracy in our tests.
- Fax-era, stamped, or partly handwritten pages: expect most printed text to come back (~70% of all words on our corpus), not the handwriting.
- Privacy: all of it happens in your browser. The scan you OCR is never uploaded — you can watch the network tab while it runs, or go offline after the page loads.
You can reproduce our real-world numbers: the FUNSD dataset is public, our metric is plain word recall, and the tool is free to test at antiupload.com/tools/ocr-pdf. If you run a comparison against any other OCR tool — including ones that upload your files — we'd genuinely like to see it.