Essential cookies keep Instavar working. Optional analytics help us understand how the site is used. Cookie Policy
Manage Cookie Preferences
Service reliability telemetry, including Sentry error monitoring and Vercel Speed Insights, stays enabled so we can secure the product and diagnose failures.
Choice-makerMatch the first model to the failure you cannot afford.
OCR selection is a routing decision: blank pages, grounding, speed, tables, and diagrams reward different first tests.
Do this first
Name the failure that would do the most damage, then begin with the route that is strongest against that failure.
Keep this boundary in view
The route is a first-test recommendation, not a production guarantee or a fixed winner across corpora.
Inspect the evidence and what would change the conclusion
Evidence layer
Cross-run workflow synthesis
Observed
Updated through 6 Aug 2026
Sample
Original 31-PDF pilot plus later 50-page operational comparisons
What supports it
The routing guidance combines reported model evidence with Instavar's scan-heavy pilot and later full-50 workflow runs.
Change our mind if
One model meets the reader's quality, latency, and failure constraints across a representative sample without routing.
Claim OCR-ROUTING-2026-03 / v2, checked 6 Aug 2026
This guide answers the deployment question behind most OCR benchmarks: which model should handle which page type.
If you searched for GLM OCR vs Mistral OCR, GLM OCR vs PaddleOCR, PaddleOCR vs Mistral OCR, dots OCR 1.5, or best OCR model 2026, this is the practical routing page. It does not claim one universal winner. It maps each workflow bottleneck to the first model worth testing.
The answer is not one universal winner. It is a routing map. A page of notes, a worksheet with diagrams, a blank scan, and a table-heavy page fail in different ways, so the best workflow sends each page type to the model that handles it best.
The short version
HunyuanOCR is the strongest first test when grounded output matters, meaning text needs to stay tied to page coordinates.
DeepSeek-OCR-2 is useful when blank-page handling and grounded fallback behavior matter.
FireRed-OCR remains the best balanced operational path for clean markdown on text-first pages.
GLM-OCR remains valuable when a question depends on a small local visual such as a graph, apparatus, particle diagram, or reaction scheme.
Qianfan, dots.ocr-1.5, PaddleOCR-VL-1.5, and managed APIs still belong in the map when their specific workflow constraints match.
Update (Mar 2026): The newer full-50 workflow benchmark widened the practical ranking beyond the original FireRed versus GLM routing story. Hunyuan is now the strongest grounded workflow, DeepSeek is the second grounded workflow and the only one to detect all 3/3 blank pages in the current full-50 run, FireRed remains the best balanced workflow, and GLM remains the fastest normal-case workflow. Qianfan is now a promoted workflow and belongs in the routing map as the markdown-oriented fallback lane. A page-level router across all five promoted workflows (FireRed, GLM, Hunyuan, DeepSeek, Qianfan) is operational and under active iteration, but not yet promoted as a default - see Section 10 for the early benchmark results. That means the deployment answer is now a five-lane map, not just a single FireRed/GLM split.
The decision path
Most OCR comparisons start with the benchmark table. We start with page failure modes.
The scan-heavy pilot first made GLM-OCR look like the safest default. That changed after the FireRed-OCR wrapper stopped hallucinating on near-blank pages and preserved page images. The later workflow benchmark then added
Local test / OCR-ROUTING-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.
Use Codex to test this bounded OCR claim in my local environment.
Source: https://instavar.com/research/ocr/choose-an-ocr-model-by-workflow
Claim ID: OCR-ROUTING-2026-03
Claim version: v2, checked 6 Aug 2026
Claim: OCR selection is a routing decision: blank pages, grounding, speed, tables, and diagrams reward different first tests.
Observed evidence: The routing guidance combines reported model evidence with Instavar's scan-heavy pilot and later full-50 workflow runs.
Evidence layer: Cross-run workflow synthesis.
Sample: Original 31-PDF pilot plus later 50-page operational comparisons.
Boundary: The route is a first-test recommendation, not a production guarantee or a fixed winner across corpora.
Potential falsifier: One model meets the reader's quality, latency, and failure constraints across a representative sample without routing.
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.
Hunyuan
,
DeepSeek
, and
Qianfan
as promoted lanes.
That is why the recommendation is workflow-first:
start from the page type
decide whether text, coordinates, blank-page safety, speed, or managed infrastructure matters most
test the model that best matches that bottleneck
use a router when one document contains several page types
GLM OCR vs PaddleOCR: use GLM first for local visual reasoning; keep PaddleOCR-VL-1.5 in the shortlist when the surrounding Paddle stack matters.
GLM OCR vs Mistral OCR: use GLM when self-hosting and local visual regions matter; use Mistral OCR 3 when managed API setup speed matters more than owning inference.
dots.ocr-1.5 vs document OCR: use dots when OCR is part of broader web, screen, scene, or SVG parsing; do not make it the default for scan-heavy school PDFs without your own benchmark.
The pain behind those shortcuts is practical. In Mistral API threads, users report queue stalls on PDF OCR jobs. In a separate Mistral refusal thread, stamps, signatures, logos, and bitmaps changed whether the API returned text or image markdown. In GLM-OCR discussions, users ask for comparisons against Paddle and DeepSeek and report Ollama setup issues. In PaddleOCR-VL-1.5 discussions, the recurring concerns are tables, repetition, CPU speed, and ROCm or Vulkan support. In a book OCR pipeline thread, users care about folder-level processing, mixed pages, handwriting, German letters, and local model serving.
Use this pain-driven map before choosing a stack:
Intent
First decision
Practical answer
Managed API vs self-hosted OCR
Do you need speed to first result, or control over privacy, wrappers, and fallback logic?
Use a managed API when integration speed matters and the documents can leave your infrastructure. Use self-hosted OCR when privacy, repeatable latency, wrapper patches, or per-page cost matter more.
GLM OCR vs Mistral OCR
Do you need local visual reasoning or an API call?
Choose GLM-OCR when you need self-hosting, local figure handling, and fast diagram-page routing. Choose Mistral when an API is acceptable and the corpus can tolerate vendor queueing and black-box failures.
GLM OCR vs PaddleOCR
Do you need visual locality or ecosystem depth?
Choose GLM-OCR for diagram-linked questions and fast local OCR. Keep PaddleOCR-VL-1.5 when the surrounding Paddle stack, table tooling, or model ecosystem matters.
PaddleOCR vs Mistral OCR
Do you want an open model lane or a managed document API?
Keep PaddleOCR in the shortlist for local control and stack maturity. Use Mistral only after testing queueing, rate limits, table behavior, and PDF preprocessing on your own corpus.
DeepSeek OCR vs GLM OCR
Is the expensive failure blank-page hallucination or diagram loss?
Choose DeepSeek-OCR-2 when blank detection and grounding matter. Choose GLM-OCR when speed and question-local visuals matter more.
dots OCR 1.5
Is OCR only one part of a broader visual parser?
Use dots.ocr-1.5 for OCR plus web, screen, scene, or SVG-style parsing. Do not make it the default scanned-PDF model without your own page-type benchmark.
Terms used below:
routing means choosing a model per page or page type, not picking one model for the whole document.
grounding means the OCR output includes page coordinates or region links, not just plain text.
CER means character error rate. Lower is better.
Start here
If you only need the first pass:
choose FireRed-OCR when the page is mostly notes, bullets, tables, worked answers, or formulas
choose GLM-OCR when the page is really asking the reader to interpret a small local visual
choose HunyuanOCR when you need text tied back to exact page regions and can accept slower processing
choose DeepSeek-OCR-2 when you want stronger grounding than GLM or FireRed and need better blank-page handling
choose Qianfan when you want a clean markdown-first OCR path without a grounding requirement
choose dots.ocr-1.5 when OCR is only one piece of a larger visual-language parsing workflow
keep PaddleOCR-VL-1.5 in the shortlist if you want a mature baseline with a broader surrounding document stack
choose Mistral OCR 3 or Reducto when you want a managed API and don't want to run inference infrastructure (see Section 9.5)
1 The shortest workflow-fit answer
Your workflow bottleneck
Best first model to test
Why
Highest grounded workflow output
HunyuanOCR
It is now the strongest grounded workflow in the current full-50 hands-on benchmark
Strong grounding plus strict blank-page handling
DeepSeek-OCR-2
It is the only workflow in the current full-50 run to detect 3/3 blank pages
Cleanup cost on text-heavy scans
FireRed-OCR
It became the cleanest Markdown-first default on text-first pages in the patched pilot
Diagram-linked question pages
GLM-OCR
It preserved question-local visuals more safely than the other stacks
Clean markdown without a grounding requirement
Qianfan
Promoted markdown-oriented workflow, validated at page and document level
OCR plus web, screen, scene, or SVG-style parsing
dots.ocr-1.5
It is the clearest broader parser in this group, not only a document OCR model
Mature baseline plus ecosystem depth
PaddleOCR-VL-1.5
It remains a strong OCR baseline with a wider surrounding parsing ecosystem
Mixed PDFs that alternate between notes and figure-heavy worksheet pages
Page-level routing
Different page types favour different models; see Section 10 for the router benchmark
Managed API, no GPU infrastructure, fast integration
Mistral OCR 3
1to2/1K pages, no self-hosting needed, no regional restrictions
Enterprise extraction with vendor SLA and agentic review
Reducto
a16z-backed, agentic OCR, from $0.015/page
2 What the pilot changed
The scan-heavy pilot did not support a simple “best OCR model in 2026” claim.
What changed:
early raw comparisons made GLM-OCR look like the safest overall default
once the FireRed-OCR wrapper stopped hallucinating on near-blank pages and preserved page images, the result shifted materially
after that patch, FireRed-OCR led 24/31 documents in the final 5-way run, but the remaining GLM-OCR wins were still meaningful because they were diagram-question-heavy
The practical result was that model choice changed with page type.
The newer workflow benchmark also sharpened the ranking at the workflow boundary:
Hunyuan is now the strongest grounded workflow
DeepSeek is the second grounded workflow and the strongest blank-page detector
FireRed remains the best balanced operational choice
GLM remains the fastest typical workflow
Qianfan is now a promoted workflow, adding a markdown-oriented lane to the five-workflow map
That does not replace the original routing rule. It makes the routing rule more complete.
3 When to use HunyuanOCR
Use HunyuanOCR first when grounded structured output matters more than speed.
Good fit:
extraction-heavy workflows
audit-heavy OCR review
pipelines that need dense page-coordinate grounding
cases where a human or downstream system needs to trace text back to page regions reliably
Why it works:
it is now the strongest grounded workflow in the current full-50 hands-on benchmark
it preserved far more structured anchors than GLM or FireRed
it is the clearest answer when the workflow needs grounded OCR rather than just readable markdown
Watch-outs:
it is slower than GLM and FireRed
the raw output usually needs more normalization before it becomes pleasant to read
4 When to use DeepSeek-OCR-2
Use DeepSeek-OCR-2 first when you want stronger grounding than GLM or FireRed, but do not need to beat Hunyuan.
Good fit:
OCR lanes where blank-page detection has to be strict
workflows that benefit from grounded output but do not need the densest possible coordinate stream
teams that want a second grounded option instead of relying on one model family only
Why it works:
it is now the second grounded workflow in the current full-50 hands-on benchmark
it was the only workflow in that run to detect all 3/3 blank pages
it preserved materially more grounding than GLM or FireRed
Watch-outs:
it is the slowest current workflow in the measured set
it is started as a helper job rather than an always-on service, so startup time makes it look slower than the lighter service paths
5 When to use FireRed-OCR
Use FireRed-OCR first when the expensive failure mode is structural cleanup on text-first pages.
Good fit:
revision notes
bullet-heavy teaching pages
answer keys
formula-heavy explanations
tables that still need to read linearly in Markdown
Why it works:
the structural OCR focus is real, not just branding
once blank-page handling and page-image preservation were fixed, its text-first output was often cleaner than the compact OCR baselines
it is the better default when the page is mostly meant to be read top-to-bottom
Watch-outs:
pages where the answer depends on a small local visual instead of the surrounding prose
worksheet pages with many inline answer-option figures
pages where a reaction scheme or apparatus needs to stay tied to a specific nearby sentence
FireRed-OCR is the best first test when the main cost is messy Markdown, not missing diagrams.
6 When to use GLM-OCR
Use GLM-OCR first when the page is visually local and the text depends on that locality.
Good fit:
question pages that say “the diagram below”
apparatus-linked practical questions
particle-box choices
reaction-network questions
small graphs embedded inside a worksheet question
Why it works:
it preserved inline regions more safely than the other models in the pilot
it remained the safer choice on diagram-question-heavy documents even after the FireRed-OCR pipeline improved
the production issue here is not only recognition accuracy but keeping the right visual tied to the right question
Watch-outs:
long text-heavy notes where its raw Markdown tends to be noisier than the best FireRed-OCR output
pages where the main job is reading prose, tables, or answers, not preserving local diagrams
If the question breaks once the inline figure disappears, GLM-OCR should stay in the routing path.
7 When to use dots.ocr-1.5
Use dots.ocr-1.5 when your real requirement is broader than document OCR.
Good fit:
OCR plus web page parsing
OCR plus screen parsing
OCR plus scene text
workflows where SVG-like structure or non-document visual parsing also matters
Why it works:
it is positioned more clearly as a broader visual parser than as a narrow document OCR specialist
it deserves a slot when one stack may need to cover several parsing modes, not just scanned PDFs
Watch-outs:
as the default OCR engine for scan-heavy school notes or worksheets
when your hardest pages are text-heavy PDFs and your main cost is Markdown cleanup
In the internal pilot, dots.ocr-1.5 won only 2/31 documents in both the raw 3-way and patched 5-way comparisons. That does not make it unimportant. It means its main value is different from the main value of GLM-OCR or FireRed-OCR.
8 When to keep PaddleOCR-VL-1.5 in the shortlist
Keep PaddleOCR-VL-1.5 in the shortlist when you want a strong OCR baseline with a broader ecosystem around it.
Good fit:
teams that care about ecosystem maturity as much as one model score
document pipelines that may expand into broader modular parsing workflows
OCR teams that want a serious baseline even if it is not the final default for every page type
Why it still belongs:
it is still one of the strongest public OCR baselines in this generation
it has a fuller surrounding ecosystem than the newer challengers
it is useful when the model decision is really a stack decision
Watch-outs:
in this specific Markdown-first, scan-heavy comparison, it was not the main story once FireRed-OCR was patched and GLM-OCR was already present as the diagram-safe baseline
9 When to use Qianfan
Use Qianfan when you want a workflow-validated markdown-first OCR path without a grounding requirement.
Good fit:
text-first pages where clean readable markdown matters more than coordinate-rich output
pipelines where the grounding-heavy lane is already covered by Hunyuan or DeepSeek and you need a lighter fallback
teams building a multi-lane router that needs a validated markdown-oriented option alongside always-on service workflows
cases where FireRed is occupied or over-committed and a second text-first lane adds throughput headroom
Why it belongs:
it is now a promoted workflow in the validated set alongside FireRed, GLM, Hunyuan, and DeepSeek
its workflow path is tested at both page and document level
its markdown output is clean and relatively consistent on text-first pages
Watch-outs:
it does not beat FireRed on balanced text-first pages, so do not prefer it when FireRed is available and the page is clearly text-first
grounding is sparse - it is not an alternative when coordinate-rich anchors matter
it is slower than GLM and FireRed in median operation
Qianfan earns its place as the markdown-oriented fallback lane in a multi-workflow router, not as the primary choice for any single page type.
9.5 When to use a commercial OCR API instead
The models above are all open-source or open-weight. If you want a managed API and can accept the pricing, two commercial options are worth evaluating alongside your open-source shortlist.
Mistral OCR 3
Product: Managed API (mistral-ocr-2512). No model weights available.
Pricing:2per1,000pages(1 in batch mode).
License: Apache 2.0 for the API usage terms. No regional restrictions (unlike some Chinese-origin models).
Good fit:
teams that want an API call and don't want to run inference infrastructure
workflows where 1to2/1,000 pages is acceptable and you need fast integration
cases where regional compliance matters (Mistral has no PRC-origin licensing concerns)
Watch-outs:
no model weights, no self-hosting option - you are locked to the API
no public evaluation methodology or benchmark dataset from Mistral
no open-source ecosystem - all coverage is third-party (VentureBeat, InfoQ, PyImageSearch)
if you want to evaluate Mistral OCR 3 against your own corpus, you pay per page during evaluation
Reducto
Product: Parse API + Extract + Split + Edit endpoints. Agentic OCR that reviews and corrects outputs in real-time.
Pricing: From $0.015/page with volume discounts.
Funding:108Mtotal(75M Series B from a16z, Feb 2026).
Good fit:
enterprise document intelligence pipelines with structured extraction requirements
teams that value vendor stability (well-funded, a16z-backed)
workflows where the API needs to do more than OCR - extraction, splitting, editing in one call
Watch-outs:
no open-source core product - you are locked to the API
the blog is case-study oriented with no technical architecture content
no community engagement (no Discord, no GitHub for core product)
they released RolmOCR (fine-tuned olmOCR variant) as an open-source contribution, which shows ecosystem engagement but does not make the core product open
How to position commercial APIs in a routing decision
Decision factor
Favour open-source
Favour commercial API
Cost sensitivity
✅ Free inference once deployed
❌ Per-page pricing adds up at scale
Infrastructure team available
✅ Self-host on your own GPUs
❌ API eliminates infra work
Corpus-specific tuning needed
✅ Can fine-tune or patch wrappers
❌ No fine-tuning on commercial APIs
Compliance / data residency
✅ Data never leaves your infrastructure
❌ Data sent to third-party servers
Speed to first result
❌ Setup, model download, GPU provisioning
✅ API call in minutes
Production SLA required
❌ Self-managed uptime
✅ Vendor SLA (check terms)
For most teams doing the kind of scan-heavy OCR we benchmark here, the open-source routing approach wins because the per-page cost advantage compounds at volume and the ability to patch wrappers (as we did with FireRed blank-page handling) is critical for production quality. Commercial APIs are worth evaluating when you need speed to first result and don't have GPU infrastructure.
10 Router v2 - page-level routing across the promoted set
The manual lane map above works when you know the page type in advance. For mixed corpora where page types vary unpredictably, a page-level router that selects the backend automatically is the practical answer.
We are actively iterating on a page-level router across FireRed, GLM, Hunyuan, DeepSeek, and Qianfan. Current route policy:
clean text-first pages → FireRed
diagram-dependent pages, or pages where image regions must stay tied to text → GLM
structured dense tables or formula-sparse layout pages → Hunyuan
low-contrast or blank-suspect pages → DeepSeek
markdown-oriented text-first fallback → Qianfan
near-blank pages → blank gate without model invocation
Early benchmark on a 10-page chemistry mixed slice:
Workflow
Text artifact score
Visual anchors
Expected anchor matches
Blank passes
FireRed
51
0
0/13
0/1
GLM
4
12
0/13
1/1
Hunyuan
0
303
13/13
1/1
Qianfan
5
14
0/13
1/1
Router v2
28
179
6/13
1/1
Mean latency on that slice: 8.77 s/page (backend mix: FireRed 3, GLM 2, Hunyuan 3, DeepSeek 1, blank gate 1).
What that shows: the routed slice beats FireRed, GLM, and Qianfan on grounded coverage for this chemistry page mix. It still trails Hunyuan on pure grounded accuracy (6/13 vs 13/13 expected anchor matches). On a larger 50-page slice, the router picked the lighter FireRed and GLM paths too often, which capped the quality ceiling and collapsed anchor matches.
The router is operational infrastructure and is actively improving. It is not a promoted default. Use the manual routing rule in Section 11 for production decisions until the routing policy closes more of the quality gap.
11 The practical routing rule
If you only want one routing policy from this article, use this:
If the workflow needs dense grounded structure for extraction or audit, start with HunyuanOCR.
If you need strong grounding and the cleanest blank-page handling, but can tolerate the slowest workflow in the set, evaluate DeepSeek-OCR-2.
If the page is mostly notes, bullets, tables, answers, or formulas, start with FireRed-OCR.
If the page depends on a small inline graph, apparatus, particle diagram, or reaction scheme, route it to GLM-OCR.
If you want a markdown-oriented fallback lane without a grounding requirement, use Qianfan.
If the workflow needs OCR plus broader web, screen, scene, or SVG-style parsing, evaluate dots.ocr-1.5 as a separate lane.
Keep PaddleOCR-VL-1.5 as a mature baseline when the surrounding parsing ecosystem matters, not just one page-level outcome.
That routing rule is more useful in production than arguing about a single universal winner.
12 What this means for mixed documents
Some PDFs should not be assigned to one model end to end.
That was the clearest lesson from the mixed chemistry worksheet packs in the pilot:
text-heavy note pages often favored FireRed-OCR
diagram-question pages often favored GLM-OCR
grounded-output-heavy workflows now point more clearly to HunyuanOCR
DeepSeek-OCR-2 now deserves its own grounded lane when blank-page handling matters
Qianfan adds a validated markdown-oriented lane when FireRed is already committed elsewhere
broader visual parsing questions still justified a separate dots.ocr-1.5 lane
If your corpus mixes several of these, treat routing as part of the product. The early router benchmark in Section 10 shows where automated page-level routing already helps and where it still needs work.
Do not wait to invent routing after rollout.
13 Bottom line
The right OCR choice in 2026 depends less on one benchmark headline than on the kind of page that hurts you when it breaks.
choose HunyuanOCR when grounded structured output matters more than speed
choose DeepSeek-OCR-2 when you want the second grounded workflow and the strongest blank-page handling
choose FireRed-OCR when cleanup cost on text-first pages is the bottleneck
choose GLM-OCR when question-local visuals have to stay attached to the right text
choose Qianfan when you want a validated markdown-oriented lane without a grounding requirement
choose dots.ocr-1.5 when OCR is only one part of a broader parser
keep PaddleOCR-VL-1.5 in the shortlist when ecosystem depth matters
That is the cleaner way to choose a stack than publishing another “best OCR model” table without page semantics.