On-device OCR that files for you

Two rows repay a close look. On the shadow band — a bright streak across the page, the classic phone-photo failure — raw Tesseract reads essentially nothing (100% error, zero fields); Keepsake detects the failed read and re-runs with heavier binarisation, recovering it to 1.7% and 97.9% of fields. On skew, the pipeline now reads a rotated page at 0.2% against raw Tesseract's 12.3% — but that row used to say the two were tied, and the reason is worth knowing: our deskewer had never actually run. Its angle detector sheared each row sideways and then counted the dark pixels in that row, which cannot change no matter how far you shift it, so every candidate angle scored the same and the answer was always "no skew". The tie we published so proudly was measuring raw Tesseract twice.

High-accuracy mode (Premium) adds a second, deep-learning engine — PaddleOCR PP-OCRv4, running fully on-device via ONNX Runtime — beside Tesseract, and keeps whichever read is stronger per page. On the same 96-case set it lifts the overall numbers to 0.1% character error and 99.3% field accuracy, winning most on exactly the hard cases — shadows, low light and sensor noise — while a skew guard keeps the deskewing pipeline in charge of rotated pages. That guard is doing real work: the deep engine alone scores 89.1% error on skewed pages and 50.4% on phone photos, because its text boxes are axis-aligned and a rotated line does not fit one. Keeping the better of two engines is only an improvement if you can tell which is better, so we publish what each engine scores on its own. (These read 2.1% / 96.9% until July 2026 — measured, like everything else, against a deskewer that turned out never to run.)

Reproducing these requires an idle machine. We first published 0.5% from a run that had been sharing the processor with two other benchmark processes; a repeat gave 3.6%, and the raw-Tesseract control column moved too — which it cannot legitimately do, since that arm has no adaptive logic to destabilise. The figures above come from an exclusive run of the shipping build; two further exclusive runs of that same build put overall character error at 0.6–0.7% and field accuracy at 96.7–97.7%. The clean, skew, shadow and phone rows come out identical every time. The degraded rows — sensor noise and low light — move by a few points in either direction from run to run, and so does raw Tesseract's control column beside them, because the recognition model is threaded and its output depends on how the work happened to be scheduled. Treat a two-point difference on those rows as weather, not signal. If you run PurpleOCR.Benchmark accuracy on a loaded machine, expect considerably worse than that.

These numbers moved twice in July 2026. First, work on Urdu exposed a way the engine could be fooled: a preprocessing pass that turns speckle into glyphs scores well on our internal quality measure precisely because it produces more text. A plausibility check — a pass may not multiply the text it claims to recover, and a pass replacing a blank read must itself be confident — fixed that. Then chasing the skew row uncovered the dead deskewer described above. Fixing it took overall character error from 2.6% to 0.6%, word error from 4.1% to 2.0%, and field accuracy to 97.7%. Both of those were bugs we found by insisting on publishing a row we were losing.