nupdf, compared with the other ways to handle a PDF.
PyMuPDF, pypdf, pdfplumber, PDFium, Poppler and PDF Oxide, measured the same way, with the places nupdf is not the best left in.
These are measurements, not a ranking. Each tool is good at something, and the last section says when to pick one of the others.
With an agent
Thirty graded tasks, five runs each, one small-model agent a run, each allowed its own tool only: 1,045 runs. The graders use pdftotext, qpdf and MuPDF, never nupdf.
Tokens and wall time are medians over passed runs. Tools that cannot write a PDF skip the tasks that need one. Over the CLI, nupdf used slightly more tokens than the two Python arms. Tasks, graders and every run
One call
The text of every page, as a new process, start-up included: the median over 200 test files.
A long document
Pages a second over 17 documents of about 100 pages.
Measured on one Apple silicon Mac, an M5 Max, on 14 November 2026, with nupdf 0.1.0, MuPDF 1.28.6 and PDF Oxide 0.3.78. Method, versions and caveats
When to pick something else
- You are writing Python and want a library, not a tool. PyMuPDF and pypdf are libraries with years of answers behind them. nupdf is a binary, an MCP server and a Rust crate.
- You need the least memory. MuPDF's own
mutoolused less than nupdf in both tables. - You need a layout model. For reading order on complex pages, or tables in scans, a tool built on one will do better than nupdf, whose layout is MuPDF's heuristics.
- You need another language. PDF Oxide has bindings for several; nupdf has Rust and the command line.
- You have one short PDF that is mostly charts. Let a vision model read the pages.
When nupdf fits
- An agent is doing the work, and you want it to cite where an answer came from.
- The file has to change: merged, filled, cleaned or redacted, with the result checked.
- There are many files, or long ones, and reading them whole costs too much.
- The files come from outside and may be damaged or hostile.