Skip to content

Comparison

MinerU vs PaddleOCR for Chinese PDFs: which one, and why

One is a document-to-markdown pipeline, the other is a model toolkit, and MinerU's own OCR backend runs PaddleOCR's recognizer. Licences, hardware and failure modes checked against primary docs, 1 September 2026.

Last reviewed · 2 tools · 8 criteria

Verdict

If the deliverable is markdown for a RAG index and the inputs are mixed Chinese PDFs, DOCX files and scans, install MinerU and stop shopping. It handles layout, reading order, cross-page tables and LaTeX formulas in one command, and since version 3.4 its pipeline backend already gives you PaddleOCR's PP-OCRv6 recognizer without a PaddlePaddle install. Choose PaddleOCR when the document is not the unit of work: receipts, ID cards, screenshots, video frames, anything where you need per-cell coordinates rather than prose, and any case where you intend to fine-tune the recognizer on your own character set. Neither belongs on a born-digital PDF that already carries a clean text layer, where pypdfium2 or pdftext will pull the text out in milliseconds at no GPU cost.

Side by side

Criterion MinerU PaddleOCR
What you get out of the box One command in, markdown plus reading-order JSON out. Formulas to LaTeX, tables to HTML, headers, footers, footnotes and page numbers removed. Inputs: PDF, images, DOCX, PPTX, XLSX with native Office parsing.Text lines with bounding boxes by default. Markdown, JSON and DOCX come from PP-StructureV3 or the PaddleOCR-VL pipeline, which you select and configure.
Runtime and framework dependency torch, transformers and onnxruntime. No PaddlePaddle. The pipeline OCR is PaddleOCR's PP-OCRv6 running through MinerU's vendored PyTorch port (mineru.model.utils.pytorchocr).PaddlePaddle framework, version 3.2.1 or above for PaddleOCR-VL. Backends selectable across PaddlePaddle, Transformers, vLLM, SGLang, FastDeploy, MLX-VLM and llama.cpp.
Licence (checked 1 September 2026) MinerU Open Source License: Apache 2.0 plus a commercial-licence trigger above 100 million MAU or USD 20 million monthly revenue, plus a prominent-attribution duty for online services, with automatic termination on breach. Moved off AGPLv3 in 3.1.0 on 18 April 2026.Apache 2.0, unmodified, copyright PaddlePaddle Authors. PaddleOCR-VL-1.6 weights on Hugging Face are also Apache 2.0.
Current stable release 3.4.5, released 14 August 2026. A 4.0.0a6 alpha exists alongside it, published the same day.v3.7.0, released 11 June 2026, introducing PP-OCRv6.
Layout, tables and coordinates Cross-page table merging, images recognised inside tables, truncated paragraph merging, chart parsing. Layout and span boxes in the intermediate JSON, no table-cell-level coordinates.PP-StructureV3 exposes table cell coordinates and text coordinates. PaddleOCR-VL-1.6 adds cross-page table merging and heading hierarchy but coarser coordinate output than PP-StructureV3.
Formula extraction On by default, converted to LaTeX. Interline formula numbering recognised since 3.0; formulas inside table cells supported. MinerU2.5-Pro model card reports 97.29 dense-formula CDM.A separate formula recognition pipeline you compose, or page-level output from PaddleOCR-VL. The v3.6.0 notes claim a lead in formula recognition on OmniDocBench v1.6.
Language coverage 109 languages for OCR detection and recognition. Version 3.4 removed the Japanese, Traditional Chinese, English and Latin options and routes those to the `ch` model. Seal text and vertical text supported since 3.0.PP-OCRv6 covers 50 languages in one model (Simplified and Traditional Chinese, English, Japanese, 46 Latin-script). PP-OCRv5 multilingual recognisers cover 109 at 2M parameters. PaddleOCR-VL-1.5 expanded to 111 including Tibetan and Bengali. Seal recognition since 1.5.
Minimum hardware and OS Pipeline: pure CPU or 4GB VRAM. Hybrid and VLM engines: 8GB VRAM, Volta or later, no CPU fallback. HTTP client: 2GB VRAM. 16GB RAM minimum, 20GB disk. Python 3.10-3.13, capped at 3.12 on Windows because `ray` lacks a 3.13 wheel. Linux 2019+, macOS 14.0+.PaddleOCR-VL local inference on x64 CPU via PaddlePaddle or Transformers, documented as possibly unsuitable for production speed, memory or stability. vLLM needs CC ≥ 8.0 and CUDA ≥ 12.6; PaddlePaddle and Transformers need CC ≥ 7.0 and CUDA ≥ 11.8. macOS requires Docker. Python 3.8+, 3.9+ for the doc-parser and all extras.

Which one to pick

  • MinerU

    You are feeding a RAG index or an LLM pipeline and the unit of work is a whole document. Mixed Chinese PDFs, DOCX and scans, tables that run across pages, formulas that must survive as LaTeX, and a team that wants one command rather than a composed pipeline. Also the right pick if you have no GPU at all, because the pipeline backend runs on pure CPU and the engine backends do not. Read the licence thresholds first if you are inside a company past USD 20 million monthly revenue, or if you are putting MinerU behind a public service where the attribution clause applies.

  • PaddleOCR

    The document is not the unit of work. Receipts, ID cards, licence plates, shelf labels, screenshots, video frames, industrial line photos. Or you need table-cell and text coordinates to map output back to pixel regions for redaction, overlay or click-to-source citations. Or you intend to fine-tune the recogniser on a domain character set, where PaddleOCR's training and export path is the mature one. Also the safer pick when legal will not accept a modified Apache licence, since PaddleOCR is stock Apache 2.0 with nothing appended.

Both tools come out of the same corner of Chinese AI infrastructure. MinerU is from OpenDataLab at Shanghai AI Lab, born out of the InternLM pre-training effort. PaddleOCR is Baidu's, built on the PaddlePaddle framework. Both will turn a Chinese PDF into markdown. That is where the resemblance stops.

MinerU is a pipeline. One command, a document in, a markdown file and a JSON structure out, with headers, footers and page numbers stripped and reading order restored. PaddleOCR is a toolkit. Detection models, recognition models, layout models, formula models and structure pipelines that you assemble into whatever you are actually building.

The detail that settles most of the argument sits in MinerU's own dependency list. Its pipeline backend ships a vendored PyTorch reimplementation of PaddleOCR, visible in the package data as `mineru.model.utils.pytorchocr`, and MinerU 3.4 on 18 June 2026 upgraded that backend's OCR model to PP-OCRv6, reporting roughly 11% better OCR accuracy on OmniDocBench v1.6 as the result. So when you pick MinerU over PaddleOCR for Chinese text, you are still running Baidu's recognizer. You are simply not running Baidu's framework.

What each is actually built for

MinerU's job is the whole document. It takes PDF, images, DOCX, PPTX and XLSX, with native parsing for the Office formats rather than a round trip through PDF, and it emits markdown plus a JSON structure ordered by reading order. Formulas become LaTeX, tables become HTML, scanned and garbled PDFs trigger OCR automatically. It ships a CLI, a FastAPI server, a Gradio UI and, since 3.0, a `mineru-router` for spreading work across multiple GPUs.

PaddleOCR's job is a text line and a box around it. Everything above that is an assembly you opt into. PP-StructureV3 is the classical composed pipeline that produces markdown or JSON. PaddleOCR-VL is the single-model route, a compact vision-language model built on a NaViT-style dynamic-resolution encoder and ERNIE-4.5-0.3B, and version 1.6 landed in v3.6.0 on 28 May 2026.

That framing is the honest version of the comparison, not the marketing one. PaddleOCR is no longer OCR-only. It converts documents to markdown, JSON and now DOCX. But the toolkit shape survives: you are choosing a pipeline, wiring modules, picking an inference backend from PaddlePaddle, Transformers, vLLM, SGLang, FastDeploy, MLX-VLM or llama.cpp. MinerU makes those choices for you and gives you one flag, `--backend`, to override them.

Layout, tables and the coordinates question

On tables, MinerU 3.1.0 moved its primary VLM to MinerU2.5-Pro, which added cross-page table merging, image recognition inside tables, truncated paragraph merging and chart parsing. For Chinese annual reports and government white papers, where a single table routinely runs across four pages with the header repeated, cross-page merging is the feature that decides whether the output is usable or garbage. MinerU 3.3 then added an `effort` parameter with `medium` and `high` levels, and reports `medium` costing only 0.13 points of overall accuracy on OmniDocBench v1.6 while running 35% to 220% faster depending on platform. `medium` is now the default, and it does not do image analysis.

PaddleOCR reached the same feature from the other direction. PaddleOCR-VL-1.5 in v3.4.0 added cross-page table merging and hierarchical heading identification. But PaddleOCR keeps a card MinerU does not play: PP-StructureV3 exposes fine-grained coordinates including table cell coordinates and text coordinates, which the VL models do not. If you are building a redaction tool, a bilingual overlay, a click-to-source citation view or anything that has to point back at a pixel region on the original page, that difference is the whole project. Concede it plainly. MinerU gives you spans and layout boxes in its intermediate JSON, but PP-StructureV3 gives you the cell.

Formulas

Formula handling is where MinerU's origin shows. The project began inside InternLM's pre-training work on scientific literature, and formula extraction is not an optional module bolted on. It runs by default, converts to LaTeX, and MinerU 3.0 added interline formula numbering recognition and formulas nested inside table cells. The MinerU2.5-Pro model card reports 97.29 on dense formula parsing under CDM.

PaddleOCR has formula recognition as its own pipeline, and PaddleOCR-VL-1.6's model card and README claim a lead in formula recognition on OmniDocBench v1.6 alongside text and table. Both claims are vendor-reported on the same public benchmark, by two vendors, and neither was run head to head here. Treat the two numbers as a statement of intent rather than a ranking.

The practical split is effort. With MinerU, formula LaTeX arrives in the markdown without configuration. With PaddleOCR, you either run PaddleOCR-VL and take its page-level output, or you compose the formula module into PP-StructureV3 yourself. If your corpus is Chinese physics or engineering papers from CNKI, MinerU is the shorter road.

Language coverage, and what 109 hides

MinerU advertises OCR detection and recognition across 109 languages. PaddleOCR advertises more than 100, with PP-OCRv6 covering 50 in a single unified model (Simplified Chinese, Traditional Chinese, English, Japanese and 46 Latin-script languages), PP-OCRv5's multilingual recognisers covering 109 at only 2M parameters, and PaddleOCR-VL-1.5 expanding to 111 including Tibetan and Bengali. Those headline numbers are close enough to be useless as a tiebreaker.

The number that matters is buried in MinerU's 3.4 notes. That release removed the Japanese, Traditional Chinese, English and Latin options from OCR language selection entirely and routes those scenarios to the `ch` model. MinerU frames it as simplification, and for mixed Simplified Chinese and English documents it is one. If your corpus is Taiwanese or Hong Kong government material, or Japanese technical documentation, you have just lost the ability to pin a language-specific recogniser. PaddleOCR still lets you name the model.

Both handle the thing English-language write-ups of Chinese OCR consistently miss: seals. MinerU 3.0 added seal text recognition to the pipeline backend along with vertical text support, and PaddleOCR-VL-1.5 added seal recognition and text spotting, with 1.6 improving seals, ancient documents and rare characters. A red 印章 stamped across the signature block of a Chinese contract will defeat a generic OCR stack. Both of these were built by people who have seen one.

The licences, read rather than skimmed

PaddleOCR is Apache 2.0, unmodified, the stock text with Baidu's copyright line. The PaddleOCR-VL-1.6 weights on Hugging Face are Apache 2.0 as well. There is nothing to negotiate and nothing to escalate to counsel.

MinerU was AGPLv3 until 18 April 2026. Version 3.1.0 moved it to the MinerU Open Source License, which is Apache 2.0 plus four additional clauses. Two of those clauses matter. You need a separate commercial licence if you and your affiliates, consolidated, exceed 100 million monthly active users or USD 20 million in total monthly revenue. And if you offer an online service built on MinerU, you must indicate clearly and prominently, in the interface or in public documentation, that MinerU is used. Miss either and the licence terminates automatically with no notice required.

That relicensing was earned, not announced. MinerU 3.0.0, on 28 March 2026, removed two AGPLv3 models (`doclayoutyolo` and `mfd_yolov8`) and one CC BY-NC-SA 4.0 model (`layoutreader`), and switched its PDF rendering engine for the same reason. The maintainers had previously stated on GitHub that YOLO's AGPL made the whole repository AGPL. They fixed the cause before changing the label, which is more than most projects do.

Two things in the licence file are worth knowing before you rely on it. The English and Chinese texts are both published and they agree: 月活跃用户数超过 1 亿 and 月总收入超过 2000 万美元 match the English thresholds exactly. But the file as published carries no governing-law or dispute clause, and the copyright line still reads `© 2026 [MinerU Team]` with the square brackets intact, so the licensor is not a named legal entity. Neither point bites a normal engineering team. Both will come up in an enterprise legal review, and better from you than from them.

Hardware, and where each one breaks

MinerU publishes an unusually honest requirements table. The pipeline backend runs on pure CPU or on 4GB of VRAM. The hybrid and VLM engine backends need 8GB of VRAM and a Volta-or-later GPU or Apple Silicon, with no CPU fallback at all. Both want 16GB of RAM, 32GB recommended, and 20GB of disk. The HTTP-client backends drop that to 2GB VRAM and 2GB disk because the model runs elsewhere. Python 3.10 to 3.13, except on Windows where `ray` has no 3.13 wheel and you are capped at 3.12. Linux distributions from 2019 or later, macOS 14.0 or later.

MinerU's documented failure modes are mundane and expensive. Windows installs frequently end up without working CUDA acceleration and quietly fall back to CPU. On a bare Linux container without CJK fonts installed, text is lost while rendering PDFs to images, which is precisely the setup most people deploy Chinese document parsing into. Install the Noto CJK packages or use the Docker image. And MinerU's own README warns that complex layouts, scanned pages and handwritten content may fall short.

PaddleOCR's constraints are sharper. PaddleOCR-VL needs PaddlePaddle 3.2.1 or above. The vLLM path requires compute capability 8.0 or higher and CUDA 12.6 or higher, which rules out V100 and 2080 Ti hardware that MinerU's Volta floor still accepts. The Transformers implementation only supports element-level recognition and text spotting, not page-level document parsing. macOS users need Docker. And the documentation says plainly that local direct inference may not meet production requirements for speed, memory or stability, steering you toward running a dedicated VLM service. That is a second moving part to operate.

One genuine advantage on each side. PaddleOCR runs on Kunlunxin XPU, Ascend NPU, Intel CPU, AMD, Intel Arc, Iluvatar and MetaX. MinerU lists ten domestic chip families: Ascend, Cambricon, Enflame, MetaX, Moore Threads, Kunlunxin, Iluvatar, Hygon, Biren and T-Head. If you are deploying inside a mainland Chinese enterprise on 信创 hardware, both are live options and almost nothing else in the open document-parsing field is.

Questions

Is MinerU still AGPL?

No. MinerU 3.1.0, released 18 April 2026, moved the repository from AGPLv3 to the MinerU Open Source License, which is Apache 2.0 with four additional clauses. The groundwork was laid in 3.0.0 on 28 March 2026, which removed two AGPLv3 models (doclayoutyolo and mfd_yolov8), one CC BY-NC-SA 4.0 model (layoutreader) and swapped the PDF rendering engine. Note that the new licence is not plain Apache 2.0: commercial use above 100 million monthly active users or USD 20 million monthly revenue requires a separate licence, and online services built on MinerU must display attribution.

Does MinerU use PaddleOCR internally?

It uses PaddleOCR's models, not PaddleOCR's framework. MinerU 3.4, released 18 June 2026, upgraded its pipeline backend's OCR model to PP-OCRv6 and reported roughly 11% better OCR accuracy on OmniDocBench v1.6 as a result. The package data in MinerU's pyproject.toml exposes `mineru.model.utils.pytorchocr`, a vendored PyTorch reimplementation, and MinerU's declared dependencies list torch, transformers and onnxruntime with no PaddlePaddle anywhere. You get Baidu's recognizer without Baidu's framework install.

Which one handles Traditional Chinese better?

PaddleOCR, as of the current releases. PP-OCRv6's unified 50-language model explicitly covers Traditional Chinese alongside Simplified, and you can still name a language-specific recogniser. MinerU 3.4 removed the Traditional Chinese, Japanese, English and Latin options from OCR language selection and routes those cases to the `ch` model instead. That simplification is fine for Simplified Chinese and English documents. For Taiwan or Hong Kong material it removes a control you may want.

Can either run without a GPU?

Both can, with caveats. MinerU's pipeline backend explicitly supports pure CPU and scores 86.47 on OmniDocBench v1.6 there, while its hybrid and VLM engine backends require 8GB of VRAM on a Volta-or-later GPU with no CPU fallback. PaddleOCR-VL supports local x64 CPU inference through PaddlePaddle or Transformers, but the official documentation warns that local direct inference may not meet production requirements for speed, memory usage or stability, and recommends a dedicated VLM inference service instead. For CPU-only production on Chinese documents, MinerU's pipeline backend is the better-supported path.

Whose accuracy numbers should I believe?

Neither, as a ranking. MinerU reports 86.47 for its pipeline backend, 95.30 for VLM and 95.39 for hybrid at high effort on OmniDocBench v1.6. PaddleOCR reports over 96.3% for PaddleOCR-VL-1.6 on the same benchmark. Both are vendor self-reports on a benchmark maintained by OpenDataLab, which is also MinerU's publisher. No head-to-head evaluation was run for this comparison. Run both over 50 pages of your own corpus and count the errors yourself; on Chinese documents the failure modes that matter (seals over text, cross-page tables, vertical columns) are corpus-specific and a benchmark average will not surface them.

Sources

  1. MinerU Open Source License (LICENSE.md, bilingual) github.com
  2. MinerU README: features, hardware table, OmniDocBench scores, changelog github.com
  3. MinerU 3.1.0 release notes (licence change, 18 April 2026) github.com
  4. MinerU 3.0.0 release notes (AGPL and CC BY-NC-SA model removal) github.com
  5. MinerU pyproject.toml (dependencies, Python range, pytorchocr package data) github.com
  6. MinerU releases (3.4.5 on 14 August 2026, 4.0.0a6 alpha) github.com
  7. MinerU FAQ (Windows CUDA, WSL2 libGL, missing CJK fonts on Linux) opendatalab.github.io
  8. MinerU2.5-Pro-2605-1.2B model card (Apache 2.0 weights) huggingface.co
  9. PaddleOCR README: PP-OCRv6, PaddleOCR-VL-1.6, PP-StructureV3, changelog github.com
  10. PaddleOCR LICENSE (stock Apache 2.0) github.com
  11. PaddleOCR releases (v3.7.0 on 11 June 2026) github.com
  12. PaddleOCR-VL usage tutorial: compute capability, CUDA and backend matrix paddleocr.ai
  13. PaddleOCR installation guide: Python versions, framework requirement, hardware paddleocr.ai
  14. PaddleOCR-VL-1.6 model card (Apache 2.0, ERNIE 4.5 base, 96.33 OmniDocBench v1.6) huggingface.co
  15. PP-OCRv6 model family announcement (1.5M, 7.7M, 34.5M parameters, 50 languages) huggingface.co

Individual reviews: MinerU, PaddleOCR. All comparisons, or the full tool catalogue.