On the current independent leaderboard, the most accurate document model is PaddleOCR-VL-1.6 at 96.34, ahead of Gemini 3 Pro at 92.91 and GPT-5.2 at 86.59. The bigger finding is what is missing: AWS Textract, Azure Document Intelligence and Google Document AI publish no accuracy figure at all, and none of the three appears on any public board. We checked their own documentation and counted.
Written for US teams choosing a document extraction vendor. Every figure here was pulled from a primary source on 21 August 2026 and is linked below. Last updated August 2026.
Upload a document to extract
Drop files here or click to upload
Up to 50 files
Free plan extracts the first 5 files, the rest unlock when you upgrade
Uploading...
No leaderboard score predicts your documents. Drop in the ugliest page you have and read the fields that come back.
The most accurate document models you can measure today are small, specialized, open-weight ones. PaddleOCR-VL-1.6 leads OmniDocBench v1.7 at 96.34, with MinerU2.5-Pro and GLM-OCR just behind it, and all three are under two billion parameters. The frontier chat models are close but not ahead: Gemini 3 Pro scores 92.91 and GPT-5.2 scores 86.59. What almost nobody points out is that the three APIs most US teams are actually choosing between are not in this comparison and cannot be, because AWS, Microsoft and Google publish no accuracy number for their document APIs and submit them to no public benchmark. That is not an oversight. Accuracy on documents is so dependent on the documents that a single headline figure would be indefensible, and every vendor knows it. Which leaves you where the benchmarks cannot help: measuring the tools on your own pages, scoring the fields you actually extract, and counting how many documents a person still has to open.
This is the end-to-end leaderboard from OmniDocBench v1.7, an Apache-licensed academic benchmark published at CVPR 2025 and maintained on GitHub by OpenDataLab. We pulled it on 21 August 2026. Higher Overall is better. Text edit distance is an error measure, so lower is better there. Table TEDS scores how much of a table's structure survived, and it is usually where tools separate.
| Model | Type | Size | Overall | Text edit | Table TEDS | Availability |
|---|---|---|---|---|---|---|
| PaddleOCR-VL-1.6 | Specialized VLM | 0.9B | 96.34 | 0.0326 | 94.76 | Open weights |
| MinerU2.5-Pro | Specialized VLM | 1.2B | 95.75 | 0.036 | 93.42 | Open weights |
| GLM-OCR | Specialized VLM | 0.9B | 95.22 | 0.044 | 92.83 | Open weights |
| PaddleOCR-VL-1.5 | Specialized VLM | 0.9B | 94.93 | 0.038 | 91.67 | Open weights |
| PaddleOCR-VL | Specialized VLM | 0.9B | 94.18 | 0.040 | 90.65 | Open weights |
| Qianfan-OCR | Specialized VLM | 4B | 93.90 | 0.04 | 90.53 | Open weights |
| Youtu-Parsing | Specialized VLM | 2.5B | 93.74 | 0.044 | 92.02 | Open weights |
| Ovis2.6-30B-A3B | General VLM | 30B | 93.70 | 0.035 | 89.44 | Open weights |
| Logics-Parsing-v2 | Specialized VLM | 4B | 93.33 | 0.041 | 88.42 | Open weights |
| ABot-OCR | Specialized VLM | 2B | 93.30 | 0.037 | 88.69 | Open weights |
| FireRed-OCR | Specialized VLM | 2B | 93.26 | 0.037 | 88.04 | Open weights |
| MinerU-2.5 | Specialized VLM | 1.2B | 93.04 | 0.045 | 87.88 | Open weights |
| Gemini 3 Pro | General VLM | not stated | 92.91 | 0.064 | 89.15 | Commercial API |
| Gemini 3 Flash | General VLM | not stated | 92.62 | 0.066 | 89.29 | Commercial API |
| dots.ocr | Specialized VLM | 3B | 90.77 | 0.048 | 87.18 | Open weights |
| OpenDoc-0.1B | Specialized VLM | 0.1B | 90.67 | 0.049 | 83.88 | Open weights |
| DeepSeek-OCR 2 | Specialized VLM | 3B | 90.25 | 0.050 | 83.89 | Open weights |
| HunyuanOCR | Specialized VLM | 1B | 89.95 | 0.088 | 91.01 | Open weights |
| Qwen3-VL-235B | General VLM | 235B | 89.78 | 0.063 | 83.07 | Open weights |
| Dolphin-v2 | Specialized VLM | 3B | 89.50 | 0.069 | 84.40 | Open weights |
| OCRVerse | Specialized VLM | 4B | 88.60 | 0.063 | 82.44 | Open weights |
| MonkeyOCR-pro-3B | Specialized VLM | 3B | 88.57 | 0.074 | 84.35 | Open weights |
| GPT-5.2 | General VLM | not stated | 86.59 | 0.114 | 82.95 | Commercial API |
| Dolphin-1.5 | Specialized VLM | 0.3B | 86.52 | 0.094 | 81.43 | Open weights |
| MinerU-Pipeline | Pipeline tool | not stated | 86.47 | 0.055 | 81.88 | Open source |
| olmOCR | Specialized VLM | 7B | 85.74 | 0.139 | 83.00 | Open weights |
| Mistral OCR | Specialized VLM | not stated | 85.66 | 0.097 | 76.78 | Commercial API |
| Kimi K2.5 | General VLM | 1T | 84.53 | 0.107 | 80.76 | Commercial API |
| InternVL3.5-241B | General VLM | 241B | 83.76 | 0.130 | 74.35 | Open weights |
| Nanonets-OCR-s | Specialized VLM | 3B | 83.61 | 0.108 | 80.18 | Open weights |
| POINTS-Reader | Specialized VLM | 3B | 83.37 | 0.096 | 73.98 | Open weights |
| Marker | Pipeline tool | not stated | 78.44 | 0.157 | 65.77 | Open source |
Two things stand out on a first read. The top of the board is entirely open-weight specialized models, which means the most accurate document parsing available is also the kind you have to host and maintain yourself, and we have costed that exercise on self-hosted OCR cost. The other is that only four rows on a 32-row board are commercial APIs you can simply buy, and the best of those, Gemini 3 Pro at 92.91, is 3.43 points behind the leader.
OmniDocBench defines its headline number in the repo as a three-part average: take the normalized text edit distance, subtract it from one, multiply by a hundred, add the table TEDS score and the formula CDM score, then divide by three. So a 96.34 blends how closely the text matched, how much of the table structure survived, and how well formulas were reconstructed. It is a document parsing score, not a character accuracy rate, and the two are not interchangeable.
This matters commercially because the three components fail in different ways. A tool can transcribe every character on an invoice correctly and still score badly if it flattened a merged cell and shifted a column, which is the failure that puts a wrong number in your ledger. We wrote up that specific trap in detail on the PDF to CSV API page.
We did not assume this, we counted it. On 21 August 2026 we pulled each vendor's own overview or FAQ page, stripped the tags, and searched the text for accuracy claims and for any figure attached to them. Then we searched the independent leaderboard for the same vendor names. Both checks agree.
| Vendor | Source checked | What the page says about accuracy | Publishes a figure | On the public board |
|---|---|---|---|---|
| AWS Textract | aws.amazon.com/textract/faqs/ | The word "accuracy" appears twice, attached to no figure | No | Absent |
| Azure Document Intelligence | learn.microsoft.com Document Intelligence overview | The word "accuracy" appears once, attached to no figure | No | Absent |
| Google Document AI | cloud.google.com/document-ai/docs/overview | The word "accuracy" does not appear at all | No | Absent |
| Mistral OCR | OmniDocBench third-party evaluation | Scored by an outside benchmark, not self-published | No | 85.66 |
| PaddleOCR | Model tables in the GitHub repo | Per-model and per-language figures, openly published | Yes | 96.34 |
To be fair to all three: this is a defensible position, not a dodge. Accuracy on documents depends so heavily on scan quality, layout, language and document type that one headline figure would be misleading in most directions at once. But it does have a consequence buyers should price in. If a vendor publishes no number and joins no benchmark, there is nothing to hold them to, and the entire burden of evaluation lands on you. The vendors that do publish, mostly the open-weight projects, are easier to check and easier to hold to account. Cost, at least, is knowable in advance, and we normalize it across every vendor on the OCR API pricing comparison.
The quoted accuracy of a model is almost always its best language, and for the highest scoring open family on this board that language is not English. PaddlePaddle publishes a per-language breakdown in its own repo, and the columns are far apart. These are its numbers, not ours.
| Recognition model | Size | Chinese | English | Traditional Chinese | Japanese |
|---|---|---|---|---|---|
| PP-OCRv5_server_rec | 81 MB | 86.38 | 64.70 | 93.29 | 60.35 |
| PP-OCRv5_mobile_rec | 16 MB | 81.29 | 66.00 | 83.55 | 54.65 |
The number usually quoted for PP-OCRv5 is 86.38. That is the Chinese column. Point the same server model at English documents and the published figure is 64.70, a drop of 21.68 points on identical software.
On English, the 16 MB mobile model scores 66.00 and the 81 MB server model scores 64.70. Five times the model, slightly worse English. Nothing about the naming tells you that.
There is a dedicated English model, en_PP-OCRv5_mobile_rec, published at 85.25 on English. Same project, same license, 20 points better on your documents, and you only get it by choosing it explicitly.
The general lesson travels well beyond one project. When a vendor quotes a single accuracy figure, ask which language, which document type and which scan quality produced it, because the answer is rarely the combination sitting in your queue. If your documents are handwritten, that is its own separate problem with its own vendor-by-vendor answer, which we mapped on handwriting OCR.
Scale is the usual assumption in AI procurement, and document parsing does not obey it. OpenDoc-0.1B, a hundred-million-parameter model, scores 90.67 Overall. Qwen3-VL-235B, which is roughly 2,350 times larger, scores 89.78. Kimi K2.5 at a trillion parameters scores 84.53, more than six points below the small one. Meanwhile the entire top of the board is occupied by models under two billion parameters that were trained specifically on document structure.
The practical reading is that document parsing is a narrow, well-defined task where targeted training beats general capability. A frontier chat model has to be good at everything; a 0.9B document model only has to reconstruct a page. That is why the gap is widest exactly where structure lives: on tables, GPT-5.2 scores 82.95 and the leader scores 94.76.
A public leaderboard tells you which models are serious. It cannot tell you which one reads your remittance advices. This is the evaluation we would run, and it takes about a day.
Take 50 to 200 real pages and deliberately over-weight the bad ones: faxed, skewed, stamped, handwritten annotations, multi-page tables. A test set of clean documents will rank every vendor identically and teach you nothing.
Label only the values you actually extract, the invoice total, the account number, the dates. Character accuracy across a whole page is not the number your process depends on, and it hides the errors that cost money.
Models are updated silently and often. A score you gathered in March against one you gathered in August is not a comparison. Same inputs, same week, same person judging what counts as correct.
The commercial metric is how many documents a person still has to open. That depends on accuracy and on whether the tool flags its own uncertainty. A slightly less accurate tool with good confidence scores can be cheaper to run.
DocuOCR is not on the leaderboard above, and we are not going to quote you a number that no outside party checked. What we will say is how the system is built to fail safely: extraction returns a confidence score on every field, low-confidence values are surfaced for review instead of landing silently in your system, and you can see which line on the source document a value came from. That design matters more than two points of benchmark, because the expensive failure in document processing is not the error, it is the error nobody noticed. Upload one of your genuinely difficult documents and judge the output yourself.
The other axis of the same decision: every vendor normalized per 1,000 pages.
Page counts, file sizes and rate ceilings, vendor by vendor.
What it costs when the model on the page above is a chat model billed per token.
Where accuracy claims fall apart fastest, and which vendors actually support it.
Which call on which cloud returns structure, and on which meter.
What running the open-weight models at the top of this board actually costs.
Every number on this page came from somebody else's test set. Yours is the one that decides the project. Upload a real document, look at the fields and the confidence scores, and make the call on evidence.