MinerU is an open-source document parser from OpenDataLab that turns PDFs, images and Office files into Markdown and JSON. It sits second of 32 on the leading independent benchmark. Two things almost nobody tells you: the backend you get without a GPU scores nine points lower, and the hosted API is documented to time out on AWS and GitHub URLs.
Written for US engineering and procurement teams deciding whether to adopt MinerU. Every figure here comes 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.
MinerU is an open-source document parsing tool from OpenDataLab, the Shanghai research group behind the InternLM models. It takes a PDF, an image, a DOCX, a PPTX or an XLSX and returns Markdown plus reading-order JSON: headers, footers and page numbers stripped, tables emitted as HTML, formulas converted to LaTeX, images extracted with captions. It carries 78,883 stars, has shipped 186 tagged releases, and had code pushed to master on the day this page was written. It is one of the most actively maintained parsers in the category and it is genuinely very good.
The two facts that decide adoption are not on the front page of the repository. The first is that "MinerU" names two quite different systems and only one of them is the one on the leaderboard. The second is a documented network limitation on the hosted API that stops it fetching documents from Amazon S3.
The one to read twice if your documents live in S3. The hosted MinerU API's create-task endpoint takes a URL rather than a file upload, and the documentation attaches this note to it, verbatim: "due to network restrictions, foreign URLs such as github and aws will time out". A US team whose documents sit in an S3 bucket cannot simply hand those URLs to the hosted API and expect them to resolve. You either move the files somewhere reachable, use the separate batch upload-URL endpoint, or run MinerU yourself. This is documented by the vendor, it is a network reality rather than a defect, and as far as we can tell nobody has written it down in English before.
Second of 32 systems, at 95.75 overall on OmniDocBench v1.7, if you run the VLM backend on a GPU. The number drops to 86.47 on the pipeline backend that runs without one. That is an 8.92 point gap between two configurations of the same tool, and it is the most important thing to understand about MinerU before you benchmark it, because a laptop test and a production test can land on opposite sides of it.
Two independent sources agree on the number. OmniDocBench lists MinerU-Pipeline as its own leaderboard entry at 86.47. MinerU's own README, footnoting OmniDocBench v1.6, reports 86.47 for pipeline against 95.39 for the VLM path at effort high and 95.26 at medium. The pipeline figure is identical in both, which is a decent sign that neither is cherry-picked.
| System | Size | Overall | Table TEDS | Runs where | Licence |
|---|---|---|---|---|---|
| PaddleOCR-VL-1.6 | 0.9B | 96.34 | 94.76 | GPU | Apache-2.0, no cap |
| MinerU2.5-Pro (vlm / hybrid backend) | 1.2B | 95.75 | 93.42 | GPU, 8 GB VRAM | Apache 2.0 plus revenue cap |
| MinerU-2.5 (previous model) | 1.2B | 93.04 | 87.88 | GPU, 8 GB VRAM | Apache 2.0 plus revenue cap |
| dots.ocr | 3B | 90.77 | 87.18 | GPU | Open weights |
| DeepSeek-OCR 2 | 3B | 90.25 | 83.89 | GPU | Open weights |
| MinerU-Pipeline (pipeline backend) | not a single model | 86.47 | 81.88 | Pure CPU works | Apache 2.0 plus revenue cap |
| olmOCR | 7B | 85.74 | 83.00 | GPU | Open weights |
| Mistral OCR | not stated | 85.66 | 76.78 | Managed API | Commercial |
| Marker | not a single model | 78.44 | 65.77 | GPU helps | Weights free below $5M revenue |
| AWS Textract, Azure DI, Google Document AI | not stated | Not on the board | Not on the board | Managed API | Commercial |
One caution about what this column means. OmniDocBench's Overall metric is defined as ((1 minus text edit distance) times 100, plus table TEDS, plus formula CDM) divided by three. So 95.75 is a composite of three different skills, not a claim that 95.75 percent of characters came out right. The full board, and the finding that AWS Textract, Azure Document Intelligence and Google Document AI publish no accuracy figure and appear on no public leaderboard at all, is on our OCR accuracy comparison.
Run the vlm or hybrid backend if you have a GPU with 8 GB of VRAM, and pipeline if you do not. That is the whole decision, and the hardware floor is what forces it rather than any preference.
| Backend | pipeline | vlm and hybrid |
| Runs on pure CPU | Yes | No |
| Minimum VRAM | 4 GB | 8 GB |
| GPU generation | Optional | Volta or later, or Apple Silicon |
| System RAM | Minimum 16 GB, 32 GB recommended | Minimum 16 GB, 32 GB recommended |
| Disk | Minimum 20 GB, SSD recommended | Minimum 20 GB, SSD recommended |
| OmniDocBench score | 86.47 | 95.39 at effort high, 95.26 at medium |
| Python | 3.10 to 3.13, Windows capped at 3.12 | 3.10 to 3.13, Windows capped at 3.12 |
MinerU's own API table lists three model versions and marks them plainly: pipeline is "default", vlm is "recommended". If you call the hosted endpoint without setting model_version you get the 86.47 path, not the 95.75 one. One parameter, nine points.
Since 3.3 the hybrid backend defaults to effort=medium, which MinerU measures as 0.13 points below high on OmniDocBench v1.6 in exchange for 35 to 220 percent more speed depending on platform. That is a good default and worth knowing you are on.
The catch on effort=medium is stated in one line of the changelog: it "does not support image analysis". If you need charts and figures interpreted rather than just extracted, you have to set effort=high and accept the slower path.
It has two, and conflating them is the most common mistake in write-ups about MinerU. There is a local API, mineru-api, a FastAPI service you run yourself with a synchronous POST /file_parse endpoint and an asynchronous POST /tasks endpoint, joined by mineru-router for distributing work across several GPUs. And there is a hosted API operated by OpenDataLab at mineru.net, with token authentication and a submit-then-poll flow. The limits below are the hosted one, because those are the ones you cannot change.
| Limit | Precise parsing API | Lightweight agent API |
|---|---|---|
| Endpoint | /api/v4/extract/task and /api/v4/file-urls/batch | /api/v1/agent/parse/url and /parse/file |
| Model versions offered | pipeline (the default), vlm (marked recommended), MinerU-HTML | pipeline lightweight model only |
| File size limit | 200 MB | 10 MB |
| Page limit per file | 200 pages | 20 pages |
| Batch support | Yes, up to 200 files | No, single file |
| Output | Zip containing Markdown and JSON, exportable to docx, html and latex | Markdown only, via a CDN link |
| Call style | Asynchronous: submit then poll | Asynchronous: submit then poll |
| Daily quota | 1,000 pages per account at highest priority, then reduced priority | Not separately documented |
| Direct file upload on the task endpoint | Not supported, the endpoint takes a URL | File endpoint available |
| Fetching from AWS or GitHub URLs | Documented to time out due to network restrictions | Same network restriction applies |
The documented rule is that each account gets 1,000 pages a day of highest-priority parsing and that volume beyond 1,000 pages is processed at reduced priority. That is a throughput promise rather than a hard cap, which is a harder thing to plan a pipeline around than a straight limit.
The create-task endpoint is documented as not supporting direct file upload: you give it a URL. Combined with the foreign-URL timeout note, a US pipeline has to use the separate batch file-urls endpoint to get bytes in, which is a design detail worth discovering before you write the client.
The precise API returns a zip containing the Markdown and the JSON, with docx, html and latex available as exports. The lightweight agent endpoint returns Markdown only, as a CDN link. Neither hands you a parsed object in the HTTP response, so plan for a fetch-and-unpack step.
For how those limits compare with the file size, page count and rate ceilings on the managed alternatives, our OCR API limits comparison puts AWS, Azure and Google side by side on the same rows.
We are going to answer this differently from every other page you will find, and the reason is worth a paragraph. MinerU publishes no throughput figure. Its changelog reports speed as percentage improvements against previous versions, never as pages per hour or pages per second, on any backend. We looked. So any article quoting you a single dollar-per-1,000-pages number for MinerU has invented the denominator, and we are not going to add another invented number to the pile.
What is verifiable is the hardware rate. The VLM backends need at least 8 GB of VRAM on a Volta-generation or newer GPU. A g4dn.xlarge carries a 16 GB Tesla T4, which clears that floor, and its on-demand Linux rate in US East (N. Virginia) is $0.5260 an hour in the AWS pricing feed published August 31, 2026. Running one around the clock is $383.98 a month. Everything else is division, so here is the division, and you supply the one number only your own benchmark can give you.
| If you measure | GPU hours per 1,000 pages | Cost per 1,000 pages | Cost per 1 million pages |
|---|---|---|---|
| 100 pages per hour | 10.00 hours | $5.26 | $5,260 |
| 250 pages per hour | 4.00 hours | $2.10 | $2,104 |
| 500 pages per hour | 2.00 hours | $1.05 | $1,052 |
| 1,000 pages per hour | 1.00 hour | $0.53 | $526 |
| 2,500 pages per hour | 0.40 hours | $0.21 | $210 |
| 5,000 pages per hour | 0.20 hours | $0.11 | $105 |
| 10,000 pages per hour | 0.10 hours | $0.05 | $53 |
The formula, so you can run it against any instance and any measured rate: cost per 1,000 pages equals the hourly instance rate divided by pages per hour, times 1,000. At $0.5260 an hour, every doubling of throughput halves the per-page cost, and the whole table above is that one division at seven points.
At the volume where $383.98 of GPU buys fewer pages than the managed vendor would sell you for the same money. That threshold moves a long way depending on which managed rate you are comparing against, which is why a single break-even number for self-hosting is close to meaningless.
| Managed rate you are replacing | Break-even volume | Throughput MinerU must actually sustain |
|---|---|---|
| $0.50 per 1,000 pages | 767,960 pages a month | 1,052 pages an hour, sustained |
| $1.50 per 1,000 pages | 255,987 pages a month | 351 pages an hour, sustained |
| $3.00 per 1,000 pages | 127,993 pages a month | 175 pages an hour, sustained |
| $10.00 per 1,000 pages | 38,398 pages a month | 53 pages an hour, sustained |
Read the right-hand column as the real question. Against the $1.50 per 1,000 that AWS, Azure and Google all charge for plain text extraction, a single always-on T4 has to hold 351 pages an hour every hour of the month to break even. Against the $10.00 per 1,000 that Azure Layout and Bedrock Data Automation charge for structured output, it only has to hold 53. Structured output is where self-hosting a parser pays, and plain text is where it usually does not. The managed rates being compared against are all normalized on OCR pricing per 1,000 pages, and the same arithmetic across every open-weight reader is on self-hosted OCR cost.
Yes, for any company that is not enormous, and the threshold is written into the licence rather than left to interpretation. The MinerU Open Source License is Apache 2.0 plus additional terms, and the operative clause reads that you must obtain a separate commercial licence if you and your affiliates, on a consolidated basis, have monthly active users exceeding 100 million or total monthly revenue exceeding USD 20 million. Twenty million a month is around $240 million a year. If you are reading this to decide whether your company can use MinerU, the answer is almost certainly yes.
| Version | Licence | What it means for a US product team |
|---|---|---|
| MinerU 3.1.0 and later | MinerU Open Source License, Apache 2.0 plus additional terms | Free unless MAU exceeds 100 million or monthly revenue exceeds USD 20 million. GitHub classifies it as NOASSERTION, not as a permissive badge. |
| MinerU 3.0.0 | AGPLv3 | The release that stripped the restricted models but before the licence change. |
| MinerU below 3.0.0 | AGPLv3, plus restricted model weights | Shipped two AGPLv3 models, doclayoutyolo and mfd_yolov8, and one CC-BY-NC-SA 4.0 model, layoutreader. That last one is non-commercial. |
| Attribution obligation | Required by the additional terms | Failing it terminates the licence automatically, with no further notice required from the licensor. |
The clean licence story only holds from 3.0.0 forward. That release, on March 29, 2026, records that it "completely removed the use of two AGPLv3 models (doclayoutyolo and mfd_yolov8) and one CC-BY-NC-SA 4.0 model (layoutreader)". Read that last one carefully: CC-BY-NC-SA is a non-commercial licence. A team that pinned MinerU before 3.0.0 and has not upgraded is shipping a non-commercially-licensed model inside a commercial product, and the repository licence at the top level does not tell them so. If you have MinerU in production, check which version.
GitHub's own API classifies the MinerU repository with an SPDX identifier of NOASSERTION and a licence name of "Other", because the additional terms make it something no standard scanner recognizes. Automated licence tooling in your CI pipeline will flag it as unknown rather than as permissive, and that is the correct behavior. Budget for a human to read a three-page file. By contrast PaddleOCR is plain Apache-2.0 at every layer with no cap at all, which for some legal departments settles the question on its own.
Two commands for the normal path, and the version constraints matter more than the commands do. MinerU supports Python 3.10 to 3.13, except on Windows where its ray dependency has no 3.13 build and caps you at 3.12. Linux needs a distribution from 2019 or later. macOS needs 14.0 or later. Docker is available but only on Linux and on Windows under WSL2, so Mac users install natively.
pip install uv, then uv pip install -U "mineru[all]". The all extra pulls every core feature and works on Windows, Linux and macOS, which covers most teams. Installing from source is a git clone plus uv pip install -e .[all] if you need to patch something.
mineru -p input -o output uses the GPU path if your hardware qualifies. Add -b pipeline to force the pure-CPU backend. This is the choice that costs or saves you nine benchmark points, so make it on purpose rather than by whatever the machine happened to have.
For anything beyond a script, run mineru-api and call it over HTTP, using POST /tasks for async work. Add mineru-router if you have more than one GPU: it presents the same interface and load-balances across services. The CLI itself now starts a temporary local service if you do not pass an api-url.
What comes out is Markdown and reading-order JSON. Tables arrive as HTML rather than pipe tables, formulas as LaTeX, and page furniture like running headers and page numbers is removed so the text stays readable end to end. If Markdown is specifically what you are after, our PDF to Markdown API page covers what every other vendor emits and what it costs, and PDF to JSON API covers the typed-field route instead.
If you are comparing MinerU against another open parser, the benchmark table above is your starting point and your own documents are the tiebreak. If what you actually want is to stop operating a parsing 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 a page better. Here is that second comparison, stated fairly.
| Question | Self-hosted MinerU | A managed extraction product |
|---|---|---|
| What you pay | $383.98 a month per always-on GPU, 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 |
| Where documents are processed | Your own infrastructure, in your own region | The vendor region you selected |
| Reading a document from S3 | Trivial, it is your network | Standard on US managed APIs |
| What you get back | Markdown and reading-order JSON for the whole page | Named fields mapped to your schema |
| Confidence per business field | No. Page structure, not validated field values | Standard on document products |
| Validation and human review | You build it | Part of a workflow product |
| Export into accounting or an ERP | You build it | Included |
| Public benchmark position | Second of 32 on OmniDocBench, at 1.2B parameters | The three biggest clouds are not ranked at all |
| Licence risk | None below $20 million monthly revenue, if you are on 3.1.0 or later | A contract |
We sell the right-hand column, so weigh the rows accordingly. MinerU is second on the leading independent benchmark, its table score of 93.42 is better than almost anything else measured, its licence will never bind a normal US business, and if you have a GPU and an engineer who wants to own this, self-hosting it is the correct answer and you should do it. The case for buying was never price per page. It is that a parser hands you a clean document and a workflow hands you checked fields, routed, reviewed and posted into the system that needed them. 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 one system above MinerU on the board, at 96.34, and the only one that is plain Apache-2.0 from the code down to every model weight with no revenue cap anywhere.
Read itIBM's CPU-first parser, priced at about $0.21 per 1,000 pages, and the cheapest of the three to operate if you have no GPU budget at all.
Read itThe open model with the cleanest licence in the category, plain MIT with no revenue cap at all, and the best table score of any model its size.
Read itThe other big open-weight reader, costed from DeepSeek's own published throughput, plus the correction to the 97 percent accuracy figure everyone repeats.
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 itThe same arithmetic applied across every open-weight reader worth evaluating: real instance rates against real throughput.
Read itFile size, page count and rate ceilings on AWS, Azure and Google, on the same rows as the MinerU limits above.
Read itWhat every vendor emits when you ask for Markdown, and the finding that Markdown is a more expensive meter rather than an output toggle.
Read itEvery managed vendor normalized to one unit, so the break-even table above 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 composite benchmark score cannot tell you how a parser handles your vendor's invoice template, and MinerU publishes no throughput number you can budget against. Upload the document you were about to write a MinerU script for and see what finished, validated fields look like. If MinerU wins on your documents, use MinerU.
