How accurate is OCR, and how do I check it?

Last reviewed: October 29, 2026 · Markdown version

There is no single number to quote, and the two engines most phones rely on do not offer one. We read the developer pages for Apple's Vision text recognition and Google's ML Kit today looking for an accuracy percentage and found none (VNRecognizeTextRequest, Apple Developer Documentation and Text recognition v2, ML Kit, Google for Developers, both read 29 October 2026). What they do document are the settings and the conditions that move accuracy up or down. So the practical answer has two halves: what changes the result, and a quick way to measure it on the documents you actually have.

What the vendors document instead of a percentage

A speed-or-accuracy switch. Apple's Vision framework has two recognition levels, and Apple describes the trade plainly: "Accurate text recognition takes more time to produce a more comprehensive result", while "Fast text recognition returns results more quickly at the expense of accuracy" (VNRequestTextRecognitionLevel, Apple Developer Documentation, read 29 October 2026). An app picks one, and you usually cannot see which.

Language correction. Vision can check what it read against a language model. Apple says switching that off "returns the raw recognition results, which provides performance benefits but less accurate results" (usesLanguageCorrection, Apple Developer Documentation, read 29 October 2026). The flip side is ours to point out: a correction step favours real words, so an unusual surname or a part number is exactly where it can guess wrong. Apple's request also accepts "An array of strings to supplement the recognized languages at the word-recognition stage", which is how an app can teach it vocabulary (VNRecognizeTextRequest, Apple Developer Documentation, read 29 October 2026).

A confidence score per result. Both engines grade themselves. Apple's is "a normalized value between 0.0 and 1.0, where 1.0 represents the highest confidence" (confidence, Apple Developer Documentation, read 29 October 2026). For every block, line, word and symbol, Google's engine "returns the bounding boxes, corner points, rotation information, confidence score, recognized languages and recognized text" (Text recognition v2, ML Kit, Google for Developers, read 29 October 2026). Neither page says what score counts as reliable, and most apps never show the number to you.

The image itself. Google's Android guide gives a size rule of thumb, "each character should be at least 16x16 pixels", adds that larger than 24x24 brings "generally no accuracy benefit", and suggests "a 720x1280 pixel image might be required" for a letter-sized printed page (Recognize text in images with ML Kit on Android, Google for Developers, read 29 October 2026). What OCR is covers the focus warning on that same page.

Check it yourself: a five-minute spot test

This method is ours, not a vendor's, and it measures the thing you care about, which is whether search will find the words.

Pick three pages: your cleanest scan, your worst (a faint photocopy or a phone photo at an angle), and one with a table or small print.
Choose ten words per page that you can read with your own eyes. Mix plain words with the hard kind: a surname, a reference number, a date, a word with an accent.
Search for each one in whatever app ran the recognition. Count the hits. Eight of ten found is a different document from three of ten, even though both are "OCR'd".
Look at the misses. A miss on "Invoice" when the page clearly says Invoice usually means one letter was misread, such as an l for an I or a 0 for an O. A run of misses on one page usually means the page itself was the problem.
Copy one paragraph out and read it against the page. That catches the errors that do not stop a search but would mislead a reader, like a wrong digit in an amount.

If the worst page fails badly, rescanning it flat and well lit usually does more than switching tools. If the clean page fails, check first that the text is printed rather than handwritten, and that the script is one the engine reads.

Errors you will not catch by reading the output

Recognition that drops a word leaves no gap to notice, and a misread word looks like a typo rather than a failure. That is why the test above searches for known words instead of skimming the result. Columns and tables are the other quiet failure: the words can all be right and still come out in an order that splits a sentence across two columns, which matters for copying and much less for search. Checking whether a PDF has a text layer tells you if recognition ran at all before you test how well.

How DocFind shows you what OCR did

DocFind reads scanned PDFs on your device, then searches them like any other document, so the spot test above is one search per word. On iPhone and iPad it uses Apple's Vision at the accurate level with language correction on; on Android it uses Google's ML Kit model bundled into the app, which reads Latin-script printed text only. Matches found through OCR are labelled as such, and pages that couldn't be made searchable are reported, so a page that failed is named rather than silently empty. It makes no handwriting claim on either platform. It does not edit the PDF to correct a misread word; it never changes the files you search.