PaddleOCR is Apache-2.0, it is genuinely first on the leading independent document benchmark, and running it costs about $0.0333 per 1,000 pages of GPU compute at PaddlePaddle's own published timings. The number a US buyer has to see before committing is a different one: the general PP-OCRv5 recognizer scores 64.70 on English against 86.38 on Chinese.
Written for US engineering and procurement teams deciding whether to self-host. Every figure here is pulled from a primary source and the arithmetic is shown. 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...
Before you provision a GPU, drop in the hardest document you have and see what finished, validated fields look like.
PaddleOCR is Baidu's open-source OCR toolkit: a text detection model, a text recognition model, an optional layout and table stage, and since late 2025 a 0.9-billion-parameter vision language model called PaddleOCR-VL that reads a whole page at once. It is Apache-2.0 from the code down to the model weights, it carries 88,461 stars, and PaddleOCR-VL-1.6 currently sits first of 32 systems on OmniDocBench, ahead of every frontier chat model on the board. It is very good software and we are not going to pretend otherwise.
The cost question is where most write-ups stop at "it is free". Free to licence is not free to run. PaddlePaddle benchmarks its models on an NVIDIA Tesla T4, and AWS rents exactly one Tesla T4 as a g4dn.xlarge for $0.5260 an hour on demand in US East. Multiply the published millisecond timings by that rate and PaddleOCR costs roughly $0.0333 per 1,000 pages, against the $1.50 per 1,000 that AWS, Azure and Google all charge for plain text extraction. That is about a 45-fold difference and it is real.
The number that decides this for a US team. PaddlePaddle publishes a per-language accuracy table, and almost nobody reads past the first column. PP-OCRv5_server_rec, the 81 MB general recognizer, scores 86.38 on Chinese and 64.70 on English. The 16 MB mobile model scores 81.29 on Chinese and 66.00 on English, which means the big model is worse at English than the small one. There is a dedicated English recognizer, en_PP-OCRv5_mobile_rec, and it scores 85.25 in a 7.5 MB file. The fix is free and documented. You just have to know to make it, and the default path does not.
Between about one cent and six cents per 1,000 pages of GPU compute, depending on which model pair and which inference mode you pick. The method is short enough to check line by line. PaddlePaddle states its benchmark hardware in the docs: an NVIDIA Tesla T4 GPU and an Intel Xeon Gold 6271C CPU. AWS sells exactly one Tesla T4 as the g4dn.xlarge, and the on-demand Linux rate in US East (N. Virginia) is $0.5260 an hour in the pricing feed dated August 29, 2026. A page costs the detection time once plus the recognition time once per text line.
The assumption, stated out loud so you can change it. PaddlePaddle publishes per-module milliseconds, not pages per hour, so a page figure requires assuming how many text lines are on a page. This table assumes 40 recognized lines per page, which is a reasonable dense business document. The relationship is linear in the recognition term, so at 80 lines the standard mobile figure goes from $0.0333 to $0.0650 and the standard server figure from $0.0625 to $0.1120. Scale it to your own pages.
| Model pair | Inference mode | GPU time per page | Pages per hour | Per 1,000 pages | Per 1 million pages |
|---|---|---|---|---|---|
| PP-OCRv5 mobile det and rec | High performance | 64.8 ms | 55,590 | $0.0095 | $9.46 |
| PP-OCRv5 mobile det and rec | Standard | 227.9 ms | 15,798 | $0.0333 | $33.29 |
| PP-OCRv5 server det and rec | High performance | 164.6 ms | 21,874 | $0.0241 | $24.05 |
| PP-OCRv5 server det and rec | Standard | 428.0 ms | 8,412 | $0.0625 | $62.53 |
Worked example for the second row: PP-OCRv5_mobile_det takes 10.67 ms per image and PP-OCRv5_mobile_rec takes 5.43 ms per text line in standard mode, so 10.67 plus 40 times 5.43 is 227.87 ms per page. That is 15,798 pages an hour, and $0.5260 divided by 15,798 is $0.0000333 a page, or $0.0333 per 1,000. High performance mode uses PaddlePaddle's optimized inference path, which the docs time at 6.36 ms and 1.46 ms for the same two models.
A g4dn.xlarge running around the clock costs $383.98 a month. At $1.50 per 1,000 pages that same money buys about 255,987 pages of managed API. So the GPU box wins above roughly a quarter of a million pages a month, and it can theoretically do 11.5 million, which means you break even at about 2 percent utilization.
That break-even is the honest, uncomfortable conclusion of this whole page. Compute is cheap enough that it is nearly never the reason to buy a document API. The reason is the parts that are not compute: field mapping, validation, review of low-confidence values, and somebody on call at 2am.
The 0.9B vision model is the one topping the benchmark, and PaddlePaddle publishes no pages-per-hour or pages-per-second figure for it anywhere in the deployment docs. We could guess. We are not going to. Benchmark it on your own hardware before you budget for it.
For the managed rates those figures are being compared against, OCR pricing per 1,000 pages is the cross-vendor reference, and self-hosted OCR cost runs the same arithmetic across every open-weight reader worth evaluating.
Between 64.70 and 85.25 average recognition accuracy, and which end you land on is entirely a configuration choice you make before you ever see a result. This is PaddlePaddle's own per-language table, reproduced in full because it is buried inside a collapsed details block in the pipeline documentation and it is the single most decision-relevant table in the project for a US team.
| Recognition model | Chinese | English | Traditional Chinese | Japanese | Size |
|---|---|---|---|---|---|
| PP-OCRv5_server_rec | 86.38 | 64.70 | 93.29 | 60.35 | 81 MB |
| PP-OCRv5_mobile_rec | 81.29 | 66.00 | 83.55 | 54.65 | 16 MB |
| en_PP-OCRv5_mobile_rec | not published | 85.25 | not published | not published | 7.5 MB |
| en_PP-OCRv4_mobile_rec | not published | 70.39 | not published | not published | 7.5 MB |
| en_PP-OCRv3_mobile_rec | not published | 70.69 | not published | not published | 17.3 MB |
Source: PaddleOCR docs, docs/version3.x/pipeline_usage/OCR.en.md on the main branch, pulled August 29, 2026. Figures are average recognition accuracy in percent, higher is better.
This is the finding that reverses the normal instinct. The 81 MB server recognizer scores 64.70 on English. The 16 MB mobile recognizer, which is five times smaller and runs faster on both GPU and CPU, scores 66.00. If you followed the usual advice and picked the server model because your accuracy requirement is high, you paid five times the model footprint and 56 percent more GPU time for slightly worse English. The gap is not large, but the direction is the opposite of what everyone assumes.
en_PP-OCRv5_mobile_rec scores 85.25 in a 7.5 MB file, and the docs describe it as improving English accuracy, fixing dropped spaces and handling handwritten English better. Against the 64.70 of the general server model that is roughly a 20-point swing on the one language your documents are in, for a smaller download. There is no cost to switching. The only reason teams do not is that the general model is what every tutorial shows.
None of these figures can be reproduced by anyone outside PaddlePaddle. The test-environment block names each evaluation dataset and each one is private: the English model is scored on a "PaddleX in-house English dataset", the Chinese models on a "PaddleOCR in-house Chinese dataset covering street views, web images, documents, and handwriting, with 11,000 images". That is not unusual and it is not dishonest, but it does mean the only accuracy numbers on this page you could independently verify are the OmniDocBench ones further down. Treat the rest as vendor-reported, which is how they are labelled here.
If you install PaddleOCR 3.7 today and call the OCR pipeline without arguments, you get PP-OCRv6_medium, not PP-OCRv5. That default changed recently and it has a consequence most people have not noticed: the generation you now get by default is the one with no published per-language breakdown, so the English question this page answers becomes unanswerable from the docs the moment you accept the default.
| Recognition model | Avg accuracy | Size | Measured on | Notes |
|---|---|---|---|---|
| PP-OCRv6_medium_rec | 83.2 | 73.3 MB | PP-OCRv6 internal multi-scenario set | Current default in PaddleOCR 3.7 |
| PP-OCRv6_small_rec | 81.3 | 20.4 MB | PP-OCRv6 internal multi-scenario set | Mobile tier |
| PP-OCRv6_tiny_rec | 73.5 | 4.4 MB | PP-OCRv6 internal multi-scenario set | Edge and IoT tier |
| PP-OCRv5_server_rec | 86.38 | 81 MB | General evaluation set | The only generation with a per-language table |
| PP-OCRv5_mobile_rec | 81.29 | 16 MB | General evaluation set | Better at English than the server model |
| PP-OCRv4_server_rec_doc | 86.58 | 182 MB | General evaluation set | Document-tuned, 15,000+ characters |
| PP-OCRv4_mobile_rec | 78.74 | 10.5 MB | General evaluation set | Previous lightweight default |
Read that table carefully, because the two halves are not on the same scale. PaddlePaddle's own footnote says it verbatim: "PP-OCRv6 metrics are evaluated on an internal multi-scenario evaluation set, while PP-OCRv5/v4 metrics are based on a general evaluation set. As the evaluation sets differ, the metrics are not directly comparable." The release notes claim PP-OCRv6_medium is 5.1 percent better at recognition than PP-OCRv5_server, while the published table shows 83.2 against 86.38, a lower number. Both statements are consistent once you accept that they describe different tests. What you cannot do is line the two generations up and pick a winner, and the documentation is upfront about that.
The repository says the toolkit supports 100+ languages. PP-OCRv6 is documented as one model covering 50, including 46 Latin-script ones. PaddleOCR-VL is documented at 109. PP-OCRv5 covers four. All four claims are true of different things, so check which applies to the model you are about to deploy.
PP-OCRv6_tiny_det is a 1.9 MB detection model with 0.43 million parameters and PP-OCRv6_tiny_rec is 4.4 MB. For an edge device or an embedded scanner that is a meaningful option, and there is nothing comparable on any managed API because a managed API cannot run on your device at all.
33 tagged releases since September 2020, with v3.7.0 shipping on June 11, 2026. That is roughly one every two months. Slower than some parsers, which cuts both ways: fewer breaking upgrades to track, and a longer wait for a fix.
On English text the gap is much narrower than either project's reputation suggests, and everywhere else it is enormous. These are normalized edit distances from OmniDocBench's text recognition evaluation, where lower is better and the versions tested were PaddleOCR 2.9.1 and Tesseract OCR 5.5. It is the only independent head-to-head of the two on a public benchmark that we are aware of, and it does not say what a comparison post usually says.
| Page condition | PaddleOCR 2.9.1 | Tesseract 5.5 | Winner |
|---|---|---|---|
| English text | 0.071 | 0.096 | PaddleOCR, narrowly |
| Chinese text | 0.055 | 0.551 | PaddleOCR, by a factor of ten |
| Mixed-language text | 0.118 | 0.250 | PaddleOCR |
| White background | 0.060 | 0.439 | PaddleOCR |
| Single-color background | 0.038 | 0.328 | PaddleOCR |
| Multi-color background | 0.085 | 0.331 | PaddleOCR |
| Normal orientation | 0.060 | 0.426 | PaddleOCR |
| Rotated 90 degrees | 0.015 | 0.117 | PaddleOCR |
| Rotated 270 degrees | 0.285 | 0.969 | PaddleOCR, though both struggle |
Source: OmniDocBench text OCR evaluation, github.com/opendatalab/OmniDocBench, pulled August 29, 2026. Both projects are Apache-2.0.
Clean, English, right-side-up pages on a white background are the one case where Tesseract holds up: 0.096 against 0.071. That is a real gap and PaddleOCR still wins it, but it is not the order-of-magnitude difference the Chinese column shows, and it is probably not on its own worth rebuilding a working Tesseract pipeline for. Where PaddleOCR pulls decisively ahead is everything that is not a clean scan: colored backgrounds go from 0.439 to 0.060, and 90-degree rotated text from 0.117 to 0.015. Real accounts payable mail is full of exactly that.
Both projects return text and bounding boxes. Neither returns an invoice number, a vendor name or a total, and neither tells you how confident it is that the number it found in the bottom right is the amount due rather than the tax. That mapping is the work, and it is the same amount of work whichever engine wins the character-level comparison. It is worth being clear about that before the engine choice absorbs a sprint.
PaddleOCR-VL-1.6, a 0.9-billion-parameter model built on a NaViT-style dynamic resolution encoder and the ERNIE-4.5-0.3B language model, holds first place of 32 ranked systems on OmniDocBench with an overall score of 96.34. It beats Gemini 3 Pro by 3.43 points and GPT-5.2 by 9.75, at a fraction of their size. This is the one accuracy claim on this page that anyone can independently check.
| System | Size | Overall | Table TEDS | How you get it |
|---|---|---|---|---|
| PaddleOCR-VL-1.6 | 0.9B | 96.34 | 94.76 | Apache-2.0 open weights |
| MinerU2.5-Pro | 1.2B | 95.75 | 93.42 | Open weights, revenue-capped licence |
| GLM-OCR | 0.9B | 95.22 | 92.83 | Open weights |
| PaddleOCR-VL-1.5 | 0.9B | 94.93 | 91.67 | Apache-2.0 open weights |
| PaddleOCR-VL | 0.9B | 94.18 | 90.65 | Apache-2.0 open weights |
| Gemini 3 Pro | not stated | 92.91 | 89.15 | Managed API |
| GPT-5.2 | not stated | 86.59 | 82.95 | Managed API |
| Mistral OCR | not stated | 85.66 | 76.78 | Managed API |
| AWS Textract, Azure DI, Google Document AI | not stated | Not on the board | Not on the board | Managed API |
The Overall column is a composite, defined by the benchmark as one minus the text edit distance, times 100, plus the table TEDS score, plus the formula CDM score, divided by three. It averages three different things and it is not a character accuracy rate. It is a good relative ranking and a bad absolute promise. The full board, plus the finding that AWS Textract, Azure Document Intelligence and Google Document AI publish no accuracy figure at all and appear on no public leaderboard, is on the OCR accuracy comparison.
Yes, and this is the part where PaddleOCR quietly beats most of its open-source rivals. In this field it is common for the code to be permissive while the weights are not, or for a permissive badge on GitHub to sit above a licence with a revenue ceiling in it. PaddleOCR has neither problem. Every artifact in the chain a US legal review would look at carries the same standard Apache-2.0 terms.
| Artifact | Where it lives | Licence | What it means for you |
|---|---|---|---|
| PaddleOCR (the toolkit) | github.com/PaddlePaddle/PaddleOCR | Apache-2.0 | 88,461 stars, 11,258 forks. Ship it commercially with attribution. |
| PaddlePaddle (the framework) | github.com/PaddlePaddle/Paddle | Apache-2.0 | A required runtime dependency, so counsel reviews it too. Commits as recent as August 28, 2026. |
| PP-OCRv5 model weights | huggingface.co/PaddlePaddle/PP-OCRv5_server_rec | Apache-2.0 | The weights carry the same permissive terms as the code, which is not always true elsewhere. |
| PaddleOCR-VL and VL-1.5 weights | huggingface.co/PaddlePaddle/PaddleOCR-VL | Apache-2.0 | The 0.9B model that leads OmniDocBench, under standard permissive terms. |
| ERNIE-4.5-0.3B base model | huggingface.co/baidu/ERNIE-4.5-0.3B-Paddle | Apache-2.0 | PaddleOCR-VL is built on it, so it is in your licence chain. |
For contrast, and this is why the row above is worth reading rather than skipping: Marker publishes its model weights free only below $5 million in revenue, MinerU requires a commercial licence above $20 million in monthly revenue, and one of the OCR engines Docling can be pointed at ships under the NVIDIA Open Model License rather than a standard open-source one. All three show a permissive badge on their repository page. PaddleOCR is the one where the badge and the terms actually agree, at every layer.
People arrive at this question from two directions. If you are comparing PaddleOCR against another open engine, the answer is on your own documents and the section above gives you the two independent tables to start from. If what you actually want is to stop maintaining a recognition service, the comparison is with a managed product, and it is a question about which parts of the job you are buying rather than which model reads characters better. Here is that second comparison, stated fairly.
| Question | Self-hosted PaddleOCR | A managed extraction product |
|---|---|---|
| What you pay | About $0.03 per 1,000 pages of GPU time, plus your engineers | A published per-page rate and nothing else |
| Who runs it | You. A GPU box, a queue, a retry policy, a model upgrade path | The vendor |
| English out of the box | Depends entirely on which recognizer you selected | Whatever the vendor tuned for |
| Confidence per field | A recognition score per text line, not per business field | Standard on document products |
| Field extraction | You map text and coordinates onto your schema yourself | Named fields returned directly |
| Validation and human review | You build it | Part of a workflow product |
| Data leaves your network | Never, once the weights are cached locally | Yes, unless the vendor sells a container |
| Reproducible accuracy claim | None. Every published figure is on a private dataset | Mostly none either, which is its own finding |
| Public benchmark position | First of 32 on OmniDocBench, at 0.9B parameters | The three biggest clouds are not ranked at all |
| Cost at 1 million pages a month | About $33 of compute on the mobile pipeline | $1,500 at $1.50 per 1,000, $10,000 at $10.00 |
We sell the right-hand column, so read the cost rows with that in mind. $0.0333 per 1,000 pages genuinely is cheaper than anything we, AWS, Azure or Google will ever charge you, and if you have GPU capacity, an engineer who wants to own this, and documents you can evaluate against, self-hosting PaddleOCR is the correct answer and you should do it. The case for buying is not price per page and never has been. It is that a recognizer hands you characters and a workflow hands you checked fields. One more thing worth saying plainly: DocuOCR is a cloud product. If your documents genuinely cannot leave your network, we are not the answer either, and on-premise OCR software covers the options that are, including the ones that are not us.
The same arithmetic applied across every open-weight reader worth evaluating: real instance rates against real throughput, and where the break-even against a managed API actually sits.
Read itIBM's CPU-based parser priced the same way, at about $0.21 per 1,000 pages, plus the three separate licences a US product has to clear before shipping it.
Read itA 7B open-weight document reader priced per 1,000 pages on named GPU instances, with the pages-per-dollar figure for each.
Read itThe full OmniDocBench board, and the finding that the three biggest cloud document APIs publish no accuracy number and sit on no public leaderboard.
Read itEvery managed vendor normalized to one unit, so the $0.0333 on this page has something honest to be compared against.
Read itIf the documents genuinely cannot leave your network, the honest options, including the ones that are not us.
Read itA score on a private in-house dataset cannot tell you how a recognizer handles your vendor's invoice template. Upload the document you were about to write a PaddleOCR script for and see what finished, validated fields look like. If PaddleOCR wins on your documents, use PaddleOCR.
