Quick answer: use PyMuPDF if you want fast, reliable text extraction from digital PDFs. Use pdfplumber when tables are the whole point. Use Docling or Unstructured when you're feeding an LLM pipeline and need structured, chunk-ready output. And use a vision LLM directly when the document is a mess of scans, handwriting, or wild layouts that rule-based parsers mangle.
That's the short version. The longer version matters because "best PDF parser" depends entirely on what's inside your PDFs, and the tool that wins on a clean digital report loses badly on a scanned invoice.
Why PDF Parsing Is Still Hard
A PDF is not a document format. It's a drawing format. It stores instructions like "place this glyph at coordinate x,y" and nothing that says "this is a heading" or "these cells belong to the same table."
Every parser is reverse-engineering structure that was thrown away at export time. That's why two libraries can read the same file and disagree about paragraph order, and why multi-column layouts still trip up tools in 2026.
Keep that in mind when you evaluate anything below. There is no parser that gets every PDF right. There are only parsers with different failure modes.
The Contenders at a Glance
| Tool | Type | Speed | Tables | Scanned PDFs | License |
|---|---|---|---|---|---|
| PyMuPDF | Library | Very fast | Decent | Via OCR add-on | AGPL / commercial |
| pdfplumber | Library | Slow | Excellent | No | MIT |
| pypdf | Library | Fast | Poor | No | BSD |
| Unstructured | Library / API | Medium | Good | Yes | Apache 2.0 (open core) |
| Docling | Library | Medium | Very good | Yes | MIT |
| Marker | Library | Medium | Good | Yes | GPL (with restrictions) |
| Vision LLM (GPT, Claude, Gemini) | API | Slow | Very good | Yes | Pay per page |
PyMuPDF: The Speed Default
PyMuPDF (imported as fitz) is where I tell most people to start. It's a Python binding over MuPDF, written in C, and it's routinely an order of magnitude faster than pure-Python alternatives on big documents.
import pymupdf
doc = pymupdf.open("report.pdf")
text = "\n".join(page.get_text() for page in doc)
Three lines, and it handles the large majority of digital PDFs well. The pymupdf4llm companion package goes further and outputs Markdown with headers and lists preserved, which is exactly what you want before converting content for LLM consumption.
The catch is licensing. PyMuPDF is AGPL, so if you're shipping it inside a commercial product you either open-source your code or buy a commercial license. Plenty of teams discover this after the prototype ships. Check with legal early.
pdfplumber: The Table Specialist
pdfplumber is slow. It's also the tool I trust most when someone hands me a financial statement and asks for the numbers.
It exposes the geometric guts of each page (lines, rectangles, character positions) and uses them to reconstruct tables with settings you can tune per document:
import pdfplumber
with pdfplumber.open("statement.pdf") as pdf:
table = pdf.pages[0].extract_table()
When a table has ruling lines, pdfplumber is excellent. When a table is whitespace-aligned with no lines, you'll spend an afternoon tuning table_settings, and sometimes it still loses. But no other rule-based library gives you this much control, and its visual debugger (draw the detected cells on the page image) is genuinely great for diagnosing why extraction failed.
Use it surgically: PyMuPDF for the prose, pdfplumber for the pages you know contain tables.
Unstructured and Docling: Built for LLM Pipelines
If your PDFs are headed into a RAG system, raw text isn't enough. You want elements: titles, paragraphs, tables, lists, each labeled and ordered, because chunking quality depends on knowing where boundaries are.
That's the pitch for this category.
Unstructured partitions documents into typed elements and has connectors for basically every downstream framework (LangChain, LlamaIndex). The open-source library is good; the strategies that use layout detection models (hi_res) are noticeably better than the fast ones, and noticeably slower. The company has been steering advanced features toward its paid API, which is worth knowing before you architect around the free tier.
Docling, IBM's entry, is the one that impressed me most recently. MIT licensed, strong table structure recognition out of the box, reading-order handling for multi-column layouts, and clean Markdown or JSON export. For a self-hosted LLM ingestion pipeline in 2026, Docling is my default recommendation.
Marker deserves a mention for PDF-to-Markdown conversion of books and papers. Output quality is high, but the license restricts commercial use above a revenue threshold, so read it before you depend on it.
LLM-Based Parsing: When to Just Use a Vision Model
Here's the shift since 2024: vision LLMs got good enough and cheap enough that "send the page image to the model" is now a legitimate parsing strategy, not a hack.
A page rendered at reasonable DPI costs a fraction of a cent to process with Gemini Flash or similar lightweight models. For that you get handling of scans, rotated text, handwriting, checkboxes, and cursed layouts that no rule-based parser survives.
The failure modes are different, though, and this is the part most comparisons skip. Rule-based parsers fail loudly: you get garbled text and you know it. LLM parsers fail quietly: the model produces fluent, plausible text that is subtly wrong, like transposed digits in a table. For a legal or financial pipeline, a confident hallucinated number is worse than an obvious extraction error.
My working rule: use vision LLMs when the document defeats deterministic tools, and keep a deterministic extraction alongside for cross-checking numbers whenever the stakes are real. Hosted services like LlamaParse and Azure Document Intelligence package this hybrid approach if you'd rather buy than build.
What About Scanned PDFs?
If get_text() returns nothing, your PDF is images. Your options, in ascending cost:
- ocrmypdf (Tesseract under the hood) to add a text layer, then parse normally. Free, fine for clean scans.
- Docling or Unstructured with OCR enabled. Integrated, slower, better structure.
- Vision LLMs. Best quality on poor scans, priced per page.
Don't skip the one-line check: sample a few pages, and if the extracted text is empty or gibberish, route the document down the OCR path instead of poisoning your index with noise.
My Recommendations by Situation
- Fast text from digital PDFs: PyMuPDF, with
pymupdf4llmfor Markdown output. - Tables you need to get right: pdfplumber, tuned per document type.
- Self-hosted LLM ingestion pipeline: Docling.
- Managed pipeline with framework integrations: Unstructured.
- Scans, handwriting, chaotic layouts: a vision LLM, with deterministic cross-checks on numbers.
- Permissive license above all: pdfplumber or pypdf.
One more thing that trips up web-scale pipelines: getting the PDF is often harder than parsing it. Reports and papers live behind redirects, bot checks, and flaky hosts, and a parser can't fix a download that never arrived. If your pipeline pulls documents and pages from across the web, a fetch API like link.sc handles the retrieval side and returns web content as clean Markdown, so your parsing effort stays focused on the PDFs that actually need it. The RAG pipeline walkthrough shows how the pieces fit together.
Whatever you choose, build a small eval set of your own documents (20 PDFs, checked by hand) before committing. The benchmark repos don't know your documents. You do.
Building a pipeline that pulls documents from the web? Get a free link.sc API key and fetch any page as clean, LLM-ready Markdown.