pdfmux vs PaddleOCR-VL: OCR model or extraction orchestrator?

Direct answer: PaddleOCR-VL is a model. pdfmux is an orchestrator. PaddleOCR-VL is Baidu’s open-weight, 0.9B-parameter vision-language model that reports state-of-the-art results on OmniDocBench — strong single-pass accuracy on dense tables, formulas, and multilingual text, released under Apache 2.0 with no field-of-use restrictions. pdfmux is a Python library and MCP server that routes each page to one of several backends (PyMuPDF, RapidOCR, Docling, or a vision LLM), audits the result for confidence, and re-routes failures — PaddleOCR-VL can sit underneath pdfmux as one of those backends. Pick PaddleOCR-VL when you want one strong open-weight VLM and are willing to run GPU inference yourself. Pick pdfmux when your document mix is heterogeneous and a silent extraction failure downstream is more expensive than the extraction itself.

pdfmux vs PaddleOCR-VL: OCR model or extraction orchestrator?

PaddleOCR-VL is Baidu’s latest release in the PaddleOCR family — but it is not the same thing as “PaddleOCR” the toolkit most developers already know. The classic PaddleOCR (v4/v5) is a detection-plus-recognition pipeline: a text-detection model finds bounding boxes, a separate recognition model reads the characters inside them. It’s fast, CPU-friendly, and widely used — pdfmux’s own default OCR backend, RapidOCR, runs PaddleOCR v4 recognition models compiled to ONNX for exactly that reason.

PaddleOCR-VL is a different generation of model entirely. It’s a compact vision-language model — a dynamic-resolution visual encoder paired with a small language decoder — that does detection, recognition, layout analysis, table structure, and reading order in a single forward pass instead of a multi-stage pipeline. Baidu reports it topping the OmniDocBench leaderboard among both open and many closed document-parsing models, with the model card and papers citing accuracy in the mid-90s percentage range on that benchmark’s composite score. The code and model weights ship under Apache 2.0, and the model supports a long list of languages beyond English and Chinese, including handwriting and complex tables in a single pass.

pdfmux is a different kind of thing. It’s a Python library and MCP server that takes seven extraction backends — PyMuPDF for clean digital text, RapidOCR for scanned pages, Docling for tables, Marker for academic layouts, OpenDataLoader for complex reading order, Mistral OCR for cloud table OCR, and any vision LLM (Gemini, Claude, GPT-4o, Ollama, or a BYOK custom endpoint) for the hardest pages — and puts a classifier and an audit layer on top. Each page gets routed to the backend most likely to handle it well, scored for confidence after extraction, and re-routed to a different backend if the score is too low. pdfmux ships MIT-licensed with no field-of-use restrictions; a hosted Cloud tier at app.pdfmux.com adds BYOK key management and per-key quotas on top of the open-source core.

You can run PaddleOCR-VL standalone and never touch pdfmux. You can also configure pdfmux to call PaddleOCR-VL as one of its backends and keep the audit manifest, retry logic, and routing on top of it. Both are real, and which one you actually want depends on whether your bottleneck is raw per-page accuracy on hard documents or the operational problem of running a mixed-document pipeline in production without silent failures.

Benchmark and deployment comparison

The shape of this table is the actual point: PaddleOCR-VL is being measured as a document-parsing model on a benchmark built for that; pdfmux is being measured as a production pipeline on a benchmark built for mixed real-world batches. They’re not fungible numbers, and a page claiming otherwise is the thing to be suspicious of.

When PaddleOCR-VL is the right call

• You want one strong open-weight VLM and you’re comfortable running GPU inference. PaddleOCR-VL’s single-pass architecture handles dense tables, formulas, and multi-column layouts well, and the OmniDocBench results suggest it’s competitive with — and in some categories ahead of — larger closed models on raw document-parsing accuracy.
• Your documents are multilingual beyond English. PaddleOCR-VL’s language coverage extends past the usual OCR-engine defaults, which matters for a genuinely multilingual document set where you’d otherwise stitch together several language-specific engines.
• You want zero licensing friction, including commercial competition. Apache 2.0 on both code and weights means no OpenRAIL-style non-compete clause — unlike Chandra’s Modified OpenRAIL-M, you can build and sell on top of PaddleOCR-VL without a revenue threshold.
• You’re processing uniform batches of hard documents. If every document needs VLM-grade table and layout understanding, not just the hardest 10%, running one well-tuned VLM on every page is simpler than operating a routing layer.
• You want to own the model, not just the pipeline. With GPU infrastructure already in place, PaddleOCR-VL’s open weights give you direct control over inference and fine-tuning that a hosted API or wrapper library doesn’t.

These are not backhanded points. If two or three of them describe your situation, PaddleOCR-VL is a reasonable default and you don’t need to read further.

When pdfmux is the right call

• Your document mix is heterogeneous. Most real pipelines aren’t uniformly hard documents — they’re a mix of clean digital PDFs, scanned invoices, the occasional dense table, and the rare handwriting-heavy form. Running every page through a VLM is correct but wasteful: PyMuPDF extracts a clean digital page in milliseconds on a CPU, and the pages where PaddleOCR-VL’s full capability earns its cost are a minority. pdfmux’s classifier makes that routing decision automatically instead of sending everything through the heaviest available model.
• A silent failure costs more than the extraction itself. PaddleOCR-VL returns parsed output; it doesn’t tell you when that output is wrong. We built pdfmux’s audit-correctness harness after a 433-PDF customer batch failed silently — the pipeline exited 0, but 16 documents had near-empty extractions a downstream RAG system would have indexed as real content. A single model, however accurate on average, gives no per-document signal that a specific page needs a human look.
• You don’t want to operate GPU infrastructure for extraction. pdfmux’s default path — PyMuPDF plus RapidOCR — runs entirely on CPU. See PDF extraction without a GPU for the architecture. PaddleOCR-VL is a genuinely good model, but it’s sized to need GPU inference for practical throughput, which is infrastructure most teams don’t want to provision just for document parsing.
• You want an MCP server, not a model you load into your own runtime. pdfmux ships an MCP server so agentic pipelines can call extraction as a tool. PaddleOCR-VL is invoked from inside whatever serving stack you build around it.
• You want to compose PaddleOCR-VL with other backends behind one interface, rather than commit every page to one model regardless of need. That’s what pdfmux’s routing and self-healing retry chain are for.

If two of these describe your situation, pdfmux is probably the better architectural fit even though PaddleOCR-VL is free to run.

What’s actually shared (composition pattern)

Both tools ultimately lean on the same idea for hard pages: a model that understands layout, not just characters. PaddleOCR-VL IS that model. pdfmux ROUTES to that kind of model — PaddleOCR-VL, Gemini, Claude, GPT-4o, Mistral OCR, or a BYOK custom endpoint — only on the pages that need it, after cheaper backends have had a chance first.

The practical consequence: pdfmux can wrap PaddleOCR-VL as a backend. pdfmux’s extraction pipeline is backend-agnostic by design — any model that takes a page image and returns structured text can be slotted in behind the classifier and audit layer. If you’ve already stood up PaddleOCR-VL inference for its accuracy on hard tables and formulas, you can keep that investment and add pdfmux’s confidence scoring, manifest, and retry logic on top, instead of choosing one or the other.

This is the same composition pattern we describe for Chandra, Datalab’s end-to-end VLM — the model-vs-orchestrator framing recurs because it’s structurally true of every single-model OCR engine, open or closed. The eval harness scores PaddleOCR-VL’s output the same way it scores PyMuPDF’s or Docling’s, so “is PaddleOCR-VL actually better than the free local backends on MY documents” becomes a question with a number, not a leaderboard from a different document distribution.

How we measure quality

Every extractor comparison page should disclose its methodology, and this is pdfmux’s, applied the same way whether the backend underneath is PyMuPDF or PaddleOCR-VL:

1. Per-page confidence score. Each page gets a 0.0–1.0 score from text density, layout coherence, and OCR confidence where OCR ran. Pages under 0.50 land in the low_lt_0.50 bucket in the manifest; pages under 0.20 trigger a strict-mode failure.
2. Manifest diff. pdfmux convert --strict --min-confidence 0.20 -o ./out/ writes a manifest.json with one row per document and one block per page, so you can diff today’s run against yesterday’s and catch regressions before they reach production.
3. Regression tests against real PDFs. pdfmux’s test suite runs against actual documents that previously broke extraction, not synthetic fixtures — the same discipline the opendataloader-bench comparison is built on.
4. Preflight, not postmortem. pdfmux doctor --check <dir> scans a batch before extraction starts and flags which documents are scanned, encrypted, or truncated — so you know what you’re dealing with before the job runs, not after it fails.

Point pdfmux at a directory of PaddleOCR-VL output and the same harness scores it. That’s the honest way to settle “which one wins on my documents” — not a shared leaderboard, which neither tool fully controls, but a measurement on the actual corpus you’re shipping.

Quick code comparison

PaddleOCR-VL (self-hosted, via Transformers):

from transformers import AutoModelForCausalLM, AutoProcessor
from PIL import Image

processor = AutoProcessor.from_pretrained("PaddlePaddle/PaddleOCR-VL")
model = AutoModelForCausalLM.from_pretrained(
    "PaddlePaddle/PaddleOCR-VL", trust_remote_code=True
).eval().cuda()

image = Image.open("page.png")
inputs = processor(images=image, text="OCR:", return_tensors="pt").to("cuda")
output = model.generate(**inputs, max_new_tokens=2048)
markdown = processor.decode(output[0], skip_special_tokens=True)

pdfmux (library mode):

import pdfmux

result = pdfmux.convert("report.pdf")
print(result.markdown)
print(result.confidence)  # per-page confidence scores

pdfmux (batch mode with audit manifest):

pip install -U 'pdfmux[ocr]'
pdfmux convert ./customer-pdfs/ -o ./out/ --strict --min-confidence 0.20
cat ./out/manifest.json | jq '.summary'

pdfmux routing PaddleOCR-VL as a backend (conceptual):

from pdfmux import Client

client = Client(backend_overrides={"vlm": "paddleocr-vl-local-endpoint"})
result = client.convert("dense-financial-table.pdf")
print(result.confidence)  # audited, even though PaddleOCR-VL did the heavy page

The gap between the first two examples is the gap between a model you load and a pipeline you point at a file. It shows up the moment you go from one PDF to a thousand mixed documents — that’s where routing and the manifest earn their keep instead of running every page through the heaviest model you have.

FAQ

Is PaddleOCR-VL the same as PaddleOCR?

No, and this is a common point of confusion. “PaddleOCR” (v4/v5) is Baidu’s long-running detection-plus-recognition OCR toolkit — fast, CPU-friendly, and the model family that pdfmux’s default OCR backend, RapidOCR, is built on. PaddleOCR-VL is a newer, separate release: a vision-language model that does detection, recognition, layout, and reading order in one pass rather than a multi-stage pipeline. They share a name and a publisher, not an architecture.

Is PaddleOCR-VL more accurate than pdfmux?

On the specific thing OmniDocBench measures — single-model document parsing on dense tables, formulas, and complex layouts — PaddleOCR-VL’s published results are genuinely strong, and Baidu reports it at or near the top of that leaderboard. pdfmux scored 0.903 on opendataloader-bench, #2 of 8 engines measured, but that’s a different benchmark measuring a different thing: an end-to-end pipeline’s output after routing and audit, not one model’s raw accuracy. Neither number answers “which is more accurate on your documents” — that requires running both against your own corpus.

Can I use PaddleOCR-VL with pdfmux?

Yes, architecturally. pdfmux’s extraction pipeline is backend-agnostic — the classifier and audit layer are built to sit on top of whatever model does the actual page-to-text work. If you’re already serving PaddleOCR-VL for its accuracy on hard pages, you can route pdfmux’s hardest-page traffic to it and keep pdfmux’s confidence scoring, manifest, and retry logic wrapped around it, rather than giving up either the accuracy or the operational tooling.

Do I need a GPU to run PaddleOCR-VL?

Not strictly, but practically yes. PaddleOCR-VL is a vision-language model, and CPU inference on a model of that class is slow enough that it’s not a realistic production path for any meaningful page volume. pdfmux’s default routing avoids this problem entirely for the majority of pages by handling clean digital text with PyMuPDF (CPU, milliseconds) and scanned text with RapidOCR (CPU, sub-second) — see PDF extraction without a GPU — and only reaches for a VLM-class backend on the pages that actually need one.

Which one should I pick if I’m starting from scratch?

If every document in your pipeline needs VLM-grade table and layout understanding and you have GPU infrastructure to run it, PaddleOCR-VL is a strong, license-unencumbered choice. If your pipeline is a mix of easy and hard documents and a silently-wrong extraction is more expensive than a slow one, pdfmux’s routing and audit manifest are built for exactly that gap — and nothing stops you from putting PaddleOCR-VL behind pdfmux as the backend for your hardest pages, getting both the model’s accuracy and the pipeline’s reliability signal.

Related reading: pdfmux vs Chandra (another open-weight VLM, same model-vs-orchestrator framing), pdfmux vs Docling, pdfmux vs Marker, what OCR actually is, and PDF extraction without a GPU for the CPU-first architecture pdfmux defaults to. For the broader landscape, see the comparison hub. For LLM/agent consumption, see llms.txt.