Best OCR model in 2026: how to choose
Transcription and extraction are different jobs with different winners. What the benchmarks measure, the four ways a score misleads, and what to use when you need typed fields.
8 min readThe honest answer is that the best OCR model depends on the job you are doing, and the two jobs people call OCR are far apart. This is a buyer's guide: how to tell which job you have, what the public benchmarks do and do not tell you, and how to test candidates on your own documents in an afternoon.
The short version
If your job is the first row, this is a solved and cheap problem: roughly $2 to $4 per 1,000 pages, and the dedicated OCR models lead the public leaderboards on it. Buy on price and stop reading comparison posts, including this one.
If your job is one of the bold rows, no OCR leaderboard will answer it for you, and the rest of this post is about why.
Two jobs that get confused
Transcription. Get the words off the page, as text or Markdown, with layout roughly intact. Success is measured against a known correct transcription, and it is close to a commodity.
Extraction. Get specific typed fields out of a document whose layout you do not control, then put them in a database. Success is whether the invoice total is right, typed, on all of your documents, and whether a field that is absent comes back empty rather than invented.
Almost every public benchmark scores the first job. Most business problems are the second. That gap is the single most useful thing to understand before comparing anyone's numbers.
What the benchmarks measure
The two most quoted are OmniDocBench and OlmOCRBench. Both score full page parsing: text edit distance against ground truth, table structure similarity (TEDS), a formula metric, and reading order. OmniDocBench combines three of those into a single overall score, which is the number that ends up on vendor pages.
Four things worth knowing before you compare two of those numbers:
- Dataset version. OmniDocBench moved from 1,355 pages in v1.5 to 1,651 in v1.6, with corrected annotations and a different matching method, plus a separate 296 page hard subset. Scores across versions are not the same measurement.
- How many pages were actually run. Running a subset instead of the full set can move a score materially. In our own runs a 200 page stratified subset scored well above the full 1,651 page run on tables, with nothing else changed. If a published number does not say how many pages it covers, treat it as marketing.
- The overall score can hide a metric that silently reports zero. The formula metric needs a Linux LaTeX toolchain. Without it the scorer does not error, it returns 0.0, and that metric is a third of the composite.
- What happened to the failures. If pages that errored were dropped rather than scored, the average improves for free. Ask for the failure count alongside the score.
None of this makes the benchmarks worthless. It means a single number without a method behind it is not evidence.
Why a benchmark score is not your accuracy
Even a clean, honestly run parsing score does not predict how a system will do on your documents, for three reasons.
Document type dominates. Every system we have measured, ours included, varies enormously across document types. Slide decks and clean reports score near perfect. Dense multi column academic pages and newspapers are several times worse. A single average across a mixed benchmark tells you almost nothing about your specific mix.
Tables are the hard part, everywhere. Table structure is the weakest axis in this entire market. Complex tables, double column layouts and pages dense with equations degrade every system meaningfully. If tables carry your data, that is the only axis you should be testing.
Parsing accuracy is not field accuracy. A page can be transcribed almost perfectly and still yield the wrong total, because picking the right number out of five candidates is a different task from reading them all correctly.
If your job is extraction, here is what we do
We build Veralens, a document extraction API, so this section is us telling you what we sell. The specifics are checkable, which is the point.
You send a JSON Schema, you get that shape back. Not "JSON-ish text that usually matches". Field names, types and structure are the contract, and numbers come back as numbers.
The page and the schema go to the model together. We do not run OCR and then hand a text stream to a second model, so checkbox state, stamps, position in the layout and handwriting are still available at the moment a field is decided. Formats: PDF up to 200 pages, images, DOCX, XLSX, CSV and plain text.
Values come out normalized. Dates ISO formatted, numbers as decimals, currencies as ISO codes, whatever convention the document used. A German invoice reading 14.03.2026 and 1.234,56 arrives as "2026-03-14" and 1234.56, so you are not writing per country parsing.
An absent field comes back null. Extraction is instructed to abstain rather than produce a plausible value, because a wrong number you cannot detect is worse than a gap you can route to review.
It runs as a durable job. Create returns an id immediately, work happens behind a queue with retries and backoff, results arrive by webhook or polling. Nothing waits on an HTTP request, and a retry does not bill you twice.
Every job reports its own cost. Real input and output tokens and the dollar amount, per document. Priced per token, so there is no page definition to argue about and no per cell or per character surcharge. Measured across 1,651 pages of full page transcription, that came to $5.63 per 1,000 pages, and schema extraction costs less because output is smaller. Detail in what document extraction actually costs.
Failures are typed. A refused document, an output that ran past the model's limit, and an engine that is temporarily unavailable are three different error codes, so you can decide what to retry and what to surface. Failed jobs refund their hold in full.
What we are not claiming is a benchmark win. The public parsing leaderboards score a different job, and the extraction axis has no shared public benchmark yet. Which is exactly why the next section matters more than any score on this page.
Test it yourself, in an afternoon
This beats any comparison post, and it is not much work.
- Take twenty of your own documents. Not the vendor's sample invoice. Include your worst scan, your densest table and the one supplier with a strange layout.
- Define success as the thing you actually need. For extraction, that is field level correctness: was each field right, typed, on all twenty.
- Count and read the failures. A refusal, a timeout and a wrong value are three different problems with three different fixes. Any API that reports all three as one generic error is withholding something you need.
- Check whether absent fields come back empty. Feed it a document missing a field you asked for. A system that invents a plausible value there will cost you more than one that admits it does not know.
- Price the whole job, parse plus extract, including surcharges. See what document extraction actually costs.
Common questions
Is a general purpose LLM good enough? For occasional use, often. For a pipeline the failure mode is that field names drift between runs and absent values get filled with plausible inventions, with nothing in the response marking them. See OCR vs LLM extraction.
What is the best document extraction API? For typed fields out of varied layouts, we would obviously point you at Veralens, and the section above says exactly what you get so you can check it rather than believe it. The alternatives worth your evaluation are the specialist extraction vendors and the hyperscaler services, which mostly cost several times more per 1,000 pages and take longer to set up.
Do I need a specialist API? If you need typed fields, normalization, retries, and a cost figure per document, you either buy that or build it. The parts are well understood; how to parse unstructured data properly is the map.
Open source or hosted? Open models are viable for transcription if you already run GPUs. For extraction, the work is not the model, it is the schema handling, normalization, validation and the job infrastructure around it.
How fast can I try it? Add funds from $5, create a key, send a document. The quickstart is a few minutes, and the invoice walkthrough is a full field by field example.