The OCR field, narrowed to the models worth testing.

Compare the evidence. Choose two models to test on your own documents.

By Wei Jie Chee · 13 Feb 2026

Which OCR models deserve a first look?

Choose two contenders from the shortlist. Test them on your own documents, focusing on the errors your workflow can least afford.

Benchmark scores do not establish a universal winner or accuracy on your documents.

Evidence and limitations

How to use the shortlist

Public scores can identify contenders, but the failure a workflow cannot afford should determine the first local test.

Use the shortlist to choose two contenders, then test the failure your workflow can least afford on your own pages.

Limits

It does not establish one universal winner or accuracy on documents outside the measured slices.

Evidence layer: Reported benchmark survey plus Instavar full-50 workflow run
Observed: March 2026 workflow update
Sample: Four operational workflows on 50 pages, with public benchmark values kept separate

What supports it

The page separates author-reported public scores from one Instavar four-workflow, 50-page operational run.

Change our mind if

A different candidate repeatedly avoids the reader's costly failure on a representative local sample.

What we found

OvisOCR2 update: it led our frozen 118-page transcription audit across ten tested systems. This is a local text-error result, not a reproduction of its authors' 96.58 OmniDocBench v1.6 score. See the OvisOCR2 evidence breakdown.
The top reported OCR models are now close enough on headline benchmarks that production fit matters more than tiny score gaps.
GLM-OCR and PaddleOCR-VL-1.5 still belong in the reported OmniDocBench shortlist.
Our hands-on read is more practical: Hunyuan is strongest when coordinates matter, DeepSeek helps when blank-page handling matters, FireRed is the best balanced operational choice, and GLM remains the fastest normal-case workflow.
dots.ocr-1.5 belongs in the OCR plus broader visual parsing lane, not as the default scanned-PDF model.
Use this page to build the first shortlist, then run a fixed page-type bake-off before rollout.

Update (Mar 2026):
The public shortlist should now be read with a second layer in mind: our newer full-50 workflow benchmark across Hunyuan, DeepSeek, GLM, and FireRed.
That benchmark does not replace the public leaderboard tables below, but it does change the deployment readout: Hunyuan leads on grounded output, DeepSeek is now the second grounded workflow and the strongest blank-page detector, FireRed remains the best balanced workflow, and GLM remains the fastest normal-case path.
For the practical routing answer across those workflows plus dots.ocr-1.5 and PaddleOCR-VL-1.5, see: https://instavar.com/research/ocr/choose-an-ocr-model-by-workflow.

OvisOCR2: what we measured and what the authors report

OvisOCR2 belongs on a transcription shortlist because of measured local results, not simply because it is a newer release. Keep three different pieces of evidence separate:

Evidence	Result	What it establishes
Authors' model card	`96.58` overall on OmniDocBench v1.6	A publisher-reported document-parsing score, not our measurement
Our frozen 118-page transcription audit	Macro character error rate `0.096742`; macro word error rate `0.189194`	Lowest aggregate transcription error among our ten tested systems under this scoring contract
Our 1,651-page OmniDocBench v1.6 inference run	1,651 successful records, zero failed records, 10 generation-limit stops	Full inference coverage; the retained evaluator summary reports an error and no overall or component scores

The authors describe a 0.8B page parser and report the 96.58 score in the OvisOCR2 model card. We have not verified a local score that reproduces that claim. Finishing inference is not the same as completing evaluation, and a successful record can still contain a truncated answer.

Our matched transcription comparison

We rescored retained outputs from a 143-page run using one frozen 118-page reference set. We excluded 25 pages because their reference transcriptions were partial, not because a particular model performed badly. Every system received the same remaining pages, normalization, and failure rule.

These are the three lowest macro character-error results in that ten-system comparison. Lower is better; macro means each page has equal weight.

Claim OCR-SHORTLIST-2026-03 / v2, checked 6 Aug 2026

One ranking cannot answer four different risks.

Follow the evidence, then choose the failure your workflow cannot afford.

Measured hereFour operational workflows across one 50-page run, including three blank pages.

Reported elsewhereOmniDocBench scores published by each model author, not rerun on one shared system.

Not establishedAccuracy on your documents, universal model quality, or the quality of every returned visual anchor.

Reported benchmark score

FireRed92.94

GLM94.62

Hunyuan94.10

DeepSeek91.09

Author-reported OmniDocBench results from model papers and repositories.

Reported benchmark score

FireRed92.94

GLM94.62

Hunyuan94.10

DeepSeek91.09

Author-reported OmniDocBench results from model papers and repositories.

Choose a first model to test.

This is a four-model measured slice, not the whole OCR market. The cost of a mistake changes which result deserves attention first.

What would hurt your workflow most?

First model to test for this risk

FireRed

FireRed offers the clearest balance of speed, blank-page handling, and clean structured output.

Watch for: Early release; broad replication is still limited
Change this recommendation if: Another workflow produces fewer consequential errors or needs less cleanup on your representative sample.

Speed and grounded output

Point emphasis follows your selected risk. Positions remain the same measured speed and unverified anchor counts.

01
FireRed
Balanced structured Markdown workflow
Watch for: Early release; broad replication is still limited
92.94 reported3.328 sec/page2/3 blank48 anchors
02
GLM
Fastest normal-page workflow
Watch for: Detected none of the three blank pages
94.62 reported1.252 sec/page0/3 blank57 anchors
03
Hunyuan
Densest grounded output
Watch for: Slower and usually needs more normalization
94.10 reported6.884 sec/page2/3 blank1,517 anchors
04
DeepSeek
Strongest blank-page handling
Watch for: Slowest workflow in the measured group
91.09 reported17.591 sec/page3/3 blank926 anchors

Reported scores come from model authors and are not measurements from the same runtime as the hands-on workflow results. Changing the risk changes the editorial order, not the underlying measurements.

How to use this page

This is a market map and shortlist builder, not the final deployment rule.

The decision path is:

use reported benchmarks to remove weak candidates
use the shortlist table below to pick the first models to test
read the benchmark landscape to understand what each public score does and does not prove
use the workflow-fit guide when the decision depends on page type
use the production checklist before promoting any model

For the scan-heavy benchmarking method behind the practical routing advice, see: https://instavar.com/research/ocr/benchmarking-ocr-on-scan-heavy-pdfs.

Quick terms used below:

grounded output means the model returns text with page coordinates, so a reviewer can trace the text back to a region on the original page.
blank-page handling means the model can return nothing when a scanned page is actually empty, instead of inventing text.
OmniDocBench is a public document OCR benchmark. It is useful for shortlisting, but it is not a substitute for testing your own page types.

1) Start here: which models belong in your first shortlist?

Your priority

Recommended first model to test

Why

Local test / OCR-SHORTLIST-2026-03

Test this claim on your documents.

Copy a read-only experiment brief that asks your coding agent to preserve raw evidence, test a negative case, and return a verdict that can disagree with this page.

Follow OCR research via RSS

Preview the experiment brief

Use Codex to test this bounded OCR claim in my local environment.

Source: https://instavar.com/research/ocr/open-document-ocr-models
Claim ID: OCR-SHORTLIST-2026-03
Claim version: v2, checked 6 Aug 2026
Claim: Public scores can identify contenders, but the failure a workflow cannot afford should determine the first local test.
Observed evidence: The page separates author-reported public scores from one Instavar four-workflow, 50-page operational run.
Evidence layer: Reported benchmark survey plus Instavar full-50 workflow run.
Sample: Four operational workflows on 50 pages, with public benchmark values kept separate.
Boundary: It does not establish one universal winner or accuracy on documents outside the measured slices.
Potential falsifier: A different candidate repeatedly avoids the reader's costly failure on a representative local sample.

Safety and privacy:
- Work read-only by default and keep all documents and outputs local.
- Do not upload documents, reveal credentials, or send document contents to an external service.
- Do not install software, download large models, start paid jobs, or change my environment without asking first.
- If the available tools cannot run the comparison safely, stop with a concrete setup plan instead of pretending the claim was tested.

Test method:
1. Inspect the available OCR workflows and record their exact versions, runtime, hardware, and configuration.
2. Help me choose a small representative sample. Include a known difficult page and a negative control with expected text or structure when available.
3. Before running anything, state the primary failure we are testing and the measurement that would expose it.
4. Preserve raw outputs. Compare text fidelity, structure, blank-page behavior, grounding correctness, runtime, and cleanup effort only where those properties can actually be measured.
5. Treat anchor count as an unverified quantity until sampled anchors are checked against the page.
6. Report the result as support, contradict, mixed, or inconclusive. Explain what observation produced that verdict.
7. Name the smallest follow-up test that could change the verdict.

What did your local test say?

Save a coarse verdict in this browser. Instavar receives no document contents through this control.

3) What the benchmark evidence says (reported)

Before comparing model cards, keep three filters in mind:

Compare only like-for-like benchmarks.
Treat low-sample live leaderboard results as directional, not final.
Validate on your own corpus before production promotion.

3.0 Why one OCR leaderboard score is not enough

A single aggregate OCR score usually hides the failure that will cost you time in production.

That is the pattern builders keep running into when they compare OCR models outside a neat leaderboard. In one Reddit benchmark discussion, users pushed for cost-per-success, latency, and open-model comparisons rather than only flagship model accuracy. In a PaddleOCR-VL-1.5 discussion, users reported strong benchmark scores but still called out table failures, repetition, CPU slowness, and local hardware questions. In a scanned PDF extraction thread, the pain was not that OCR returned no text. The pain was that tables broke, columns shifted, numbers were misread, and the output still needed manual checking.

Read leaderboard scores as a shortlist signal, then test the workflow dimensions that actually fail:

OCR text accuracy: can it read the characters?
Table extraction: can it preserve rows, columns, merged cells, and numeric alignment?
Key information extraction: can it pull fields without moving values into the wrong label?
Visual QA: can it answer questions about diagrams, figures, stamps, signatures, and local images?
Long-document handling: does quality hold after many pages, not just one demo page?
Latency and cost: does the model still make sense at 1,000 pages?
Field-level reliability: can a reviewer trace uncertain values back to the page before they enter a downstream system?

That is why this page is a leaderboard and not a final answer. Use it to build the shortlist, then use the workflow guide and scanned-PDF guide to decide which model should handle each page type.

3.1 OmniDocBench snapshot

The table below consolidates reported OmniDocBench scores from model papers/cards, using v1.5 where explicitly stated.

Model	Params	OmniDocBench (reported)	Notes	Source
GLM-OCR	0.9B	94.62	Strong all-round reported score; very recent release	GLM-OCR repo
PaddleOCR-VL-1.5	0.9B	94.50	Competitive accuracy with compact footprint	PaddleOCR-VL paper
HunyuanOCR	1B	94.10	High reported score and broad task framing	HunyuanOCR report
DeepSeek-OCR-2	3B MoE decoder (~500M active) + 80M image compressor	91.09

Interpretation:

The top reported scores are now close enough that cost, failure mode, and licensing often matter more than a small benchmark gap.

3.5 FireRed-OCR early evidence snapshot

The FireRed-OCR launch matters because it includes both a technical paper and a benchmark framing centered on structural integrity rather than only text recognition.

Signal	Reported value	Source
OmniDocBench v1.5 overall	`92.94`	FireRed-OCR paper
FireRedBench overall	`74.62`	FireRed-OCR repo
Base foundation	`Qwen3-VL-2B-Instruct`	FireRed-OCR repo
Distinguishing method	Format-Constrained GRPO for formula syntax, table integrity, hierarchical closure, and text accuracy	FireRed-OCR repo

Interpretation:

FireRed-OCR is not the overall reported OmniDocBench leader, but it is now one of the clearest structure-first challengers in the open OCR field.
If your bottleneck is malformed Markdown or broken document syntax rather than pure text recognition, it belongs in the evaluation lane immediately.

3.6 What hands-on evaluation changed

Public benchmark tables are useful, but real scanned documents can still reorder the shortlist once page type and wrapper quality enter the picture. In our scan-heavy pilot, that is exactly what happened. This page should stay the market map and shortlist, not the final routing answer. For the routing rule and the underlying evidence, use:

workflow-fit guide: https://instavar.com/research/ocr/choose-an-ocr-model-by-workflow
methodology and benchmark detail: https://instavar.com/research/ocr/benchmarking-ocr-on-scan-heavy-pdfs

3.7 What the newer four-model workflow benchmark changed

The newer full-50 workflow benchmark adds a second layer on top of the public leaderboard story because it compares real operational entrypoints rather than just reported paper/model-card numbers.

Workflow	Mean sec/page	Blank pages detected	Total visual anchors	Practical readout
`FireRed`	`3.328`	`2/3`	`48`	Best balanced workflow
`GLM`	`1.252`	`0/3`	`57`	Fastest normal-case workflow
`Hunyuan`	`6.884`	`2/3`	`1517`	Strongest grounded workflow
`DeepSeek`	`17.591`	`3/3`

Interpretation:

Hunyuan now has the strongest practical case when grounded structure matters more than speed.
DeepSeek is no longer just a markdown-oriented curiosity. It is now the second grounded workflow in the measured stack, although it is also the slowest.
FireRed remains the best balanced operational choice when you want a cleaner markdown-oriented workflow.
GLM remains the fastest typical path, but it is still weak on blank-page handling.

3.2 OlmOCR-Bench snapshot

Reported from LightOnOCR-2 benchmarking (headers/footers excluded setting):

Model	OlmOCR-Bench (reported)	Context	Source
LightOnOCR-2-1B	83.2 +/- 0.9	Reported as strongest in this comparison slice	LightOnOCR-2 paper
Chandra-9B	81.7 +/- 0.9	Large model baseline in same evaluation	LightOnOCR-2 paper
olmOCR-2-8B	80.4 +/- 1.1	Strong open baseline with robust ecosystem support	LightOnOCR-2 paper

Interpretation:

A tuned 1B OCR model can match or exceed larger document VLM baselines on task-specific OCR benchmarks.

3.3 Throughput snapshot

Throughput matters because OCR cost scales with page volume, not request count.

Model	Throughput (pages/s, reported)	Hardware context	Source
LightOnOCR-2-1B	5.71	Single H100 context in authors' report	LightOnOCR-2 paper
DeepSeek-OCR family	Varies by mode and output format	Public demos emphasize extraction-mode trade-offs	DeepSeek-OCR-2
GLM-OCR	Deployment-oriented serving options published; no single canonical throughput figure in repo	Depends on serving stack (`vLLM`, `SGLang`, Ollama)	GLM-OCR repo

3.4 dots.ocr-1.5 early evidence snapshot (author-reported)

The dots.ocr-1.5 release adds important new evidence, but most of it currently comes from the model card/repo evaluation stack.

Signal	Reported value	Source
Elo on olmOCR-Bench	1089.0	dots.ocr release repo
Elo on OmniDocBench (v1.5)	1025.8	dots.ocr release repo
Elo on XDocParse	1157.1	dots.ocr release repo
OmniDocBench (v1.5) TextEdit	0.031 (lower is better)	dots.ocr release repo
OmniDocBench (v1.5) ReadOrderEdit	0.029 (lower is better)	dots.ocr release repo

Interpretation:

Useful new signal, but evaluate carefully.
The Elo setup is judged by Gemini 3 Flash in the authors' pipeline and is not a drop-in replacement for independent leaderboard results.

System	Macro character error rate	Macro word error rate	Unique page wins by character error
OvisOCR2	0.096742	0.189194	24
FireRed-OCR	0.127700	0.234079	14
Chandra-OCR-2	0.129275	0.214995	34

Model	Choose first when	Why it wins there	Watch-outs
HunyuanOCR	You need dense grounded output for extraction or audit-heavy workflows	Strongest grounded workflow in the current full-50 hands-on benchmark	Slower than GLM or FireRed; raw output usually needs more normalization
DeepSeek-OCR-2	You need stronger grounding than GLM or FireRed plus strict blank-page handling	Second grounded workflow in the current hands-on benchmark and the only one to detect `3/3` blank pages	Slowest current workflow; current helper job adds startup overhead
GLM-OCR	You need a strong default baseline across mixed documents	Top-tier reported OmniDocBench result in compact size; multiple serving paths	Very new release; long-tail behavior still needs broad replication
dots.ocr-1.5	You need one model for OCR plus web/screen/scene/SVG parsing	Broad task coverage in a single 3B model family and strong reported release benchmarks	Many benchmark claims are currently model-card/repo reported for this version
FireRed-OCR	You need stricter structural Markdown behavior with formulas and tables	Public training story explicitly targets structural hallucination and syntactic validity	Early-cycle release; benchmark evidence is still author-reported and needs broad replication
DeepSeek-OCR-2	You need markdown-oriented output and mode switching	Reading-order-focused design and dual extraction modes (`Free OCR` and structured conversion)	Validate complex tables and multilingual edge cases on your own corpus
LightOnOCR-2-1B	You process high page volume and care about cost per page	Strong reported OlmOCR-Bench + throughput profile at 1B scale	Check performance on your language/script distribution
GutenOCR	You need reliable text-to-location grounding for downstream extraction	Grounded OCR is core design objective and first-class output	Weight license is CC-BY-NC; commercial use may be constrained
HunyuanOCR	You want one compact model for broad document tasks	Strong reported compact-model results across parsing-oriented tasks	Custom community license requires legal/compliance review
PaddleOCR-VL-1.5	Your inputs are messy scans/photos and you already run Paddle tooling	Near-frontier reported OmniDocBench score with robustness framing	Confirm accuracy on your distortion mix and template families

Model	Maturity signal	What it means for rollout
GLM-OCR	Rapid early GitHub/HF uptake after launch	Fast-moving ecosystem, but still early for stability assumptions
dots.ocr-1.5	Fresh Feb 16, 2026 release with expanded task scope	High upside for multi-task use cases, but treat current results as early-cycle evidence
FireRed-OCR	March 2026 release with repo, model card, and paper all live at launch	Stronger evidence package than many brand-new challengers, but still early for stability assumptions
DeepSeek-OCR-2	Strong HF traction soon after release	Good community momentum for tooling and examples
HunyuanOCR	High visibility and broad activity across channels	More examples in the wild for compact deployment patterns
GutenOCR	Growing technical interest from doc-AI builders	Strong relevance for grounding-heavy extraction workflows

Slice	Pages	Why this slice matters
Clean digital single-column PDFs	8	Baseline text fidelity
Multi-column + sidebars + footnotes	8	Reading-order stress
Table-heavy documents	8	Structure fidelity and cell ordering
Formula-heavy documents	6	Formula extraction and sequencing
Forms/invoices/receipts	6	Region association and key-value linking
Messy photos/scans	10	Skew, warping, glare, and capture artifacts
Multilingual mixed-script pages	4	Language/layout stability

Which OCR models deserve a first look?

How to use the shortlist

Limits

What supports it

Change our mind if

What we found

OvisOCR2: what we measured and what the authors report

Our matched transcription comparison

One ranking cannot answer four different risks.

Reported benchmark score

Reported benchmark score

Choose a first model to test.

FireRed

FireRed

GLM

Hunyuan

DeepSeek

How to use this page

1) Start here: which models belong in your first shortlist?

Test this claim on your documents.

What to test before adopting it

2) What changed in OCR by February 2026

3) What the benchmark evidence says (reported)

3.0 Why one OCR leaderboard score is not enough

3.1 OmniDocBench snapshot

3.5 FireRed-OCR early evidence snapshot

3.6 What hands-on evaluation changed

3.7 What the newer four-model workflow benchmark changed

3.2 OlmOCR-Bench snapshot

3.3 Throughput snapshot

3.4 dots.ocr-1.5 early evidence snapshot (author-reported)

4) Model fit by use case

4.1 Use-case fit matrix

4.2 Adoption and maturity signals (Feb 13, 2026 snapshot)

5) A practical evaluation protocol (6 core models + challengers)

5.1 Preflight gates (before benchmarking)

5.2 50-page stratified set

5.3 Ground-truth package per page

5.4 Inference protocol (same policy for all models)

5.5 Metrics

5.6 Pass/fail thresholds

5.7 Weighted winner rule

5.8 Deployment outcome template

6) Risks and caveats before production rollout

7) Conclusion

Sources