pdfboss.dev
pdfarena: race it against hayro, pdf.js and PDFium, in your browserTry it →

A PDF engine written from scratch in Rust.

Parse, extract text, rasterize to PNG. One core, a CLI, and pythonic bindings. A clean-room reader built from the ISO 32000 spec. Safe Rust, no C dependencies, no bindings to another engine.

$pip install pdfboss$cargo install pdfboss-cli

Prebuilt abi3 wheels for CPython 3.12+, no toolchain required.

The toolkit

Point it at a path or a URL.

The CLI ships info, text, md, render, images and tui, creation via create blank|text|images, and explorer subcommands json, hex, q (jq-style queries) and obj. Each takes a local path or an http(s) URL, fetched in byte ranges rather than downloaded whole.

$ pdfboss info quarterly.pdf
$ pdfboss md quarterly.pdf
$ pdfboss render quarterly.pdf
$ pdfboss images quarterly.pdf
# explore a remote file without downloading it
$ pdfboss json https://example.com/report.pdf
$ pdfboss q quarterly.pdf '.header.version'
$ pdfboss create text notes.txt -o out.pdf
$ pdfboss tui quarterly.pdf
report.pypdfboss-py
import pdfboss

doc = pdfboss.Document("report.pdf")
text = doc.extract_text()
md = doc.extract_markdown()
png = doc[0].render(scale=2.0)  # PNG bytes
images = doc[0].extract_images()

# async, straight off the wire
doc = await pdfboss.AsyncDocument.open_url(
    "https://example.com/report.pdf"
)

Benchmarks

Measured on real PDFs.

Apple M3 Pro, 40 real-world PDFs, pdfboss 0.22.0. The fastest library measured on text extraction, open + parse, and rendering, including against the C-backed PyMuPDF.

6,850 pages/s

Text extraction: ~15× PyMuPDF, ~23× pdf_oxide.

405,000 pages/s

Open + parse: ~2.1× pdf_oxide.

144.5 pages/s

Rendering the mixed corpus: ~19% ahead of pdfium itself.

65.4 pages/s

On a 544-page JBIG2 scanned book, fastest of the four measured.

Text extraction

Apple M3 Pro · 40 real-world PDFs · pages per second, higher is better

pdfboss6,850
PyMuPDF450
pdf_oxide290

~15× PyMuPDF, ~23× pdf_oxide. Open + parse tells the same story: 405,000 pages/s to pdf_oxide’s 190,000.

Rendering

38 certified files · 888 pages · pages per second

pdfboss144.5
pypdfium2121.3
pdfplumber102.0
PyMuPDF89.5

Fastest on the mixed corpus, ~19% ahead of pdfium itself, with no C in it. pdfplumber renders via pdfium.

Scanned documents

544-page JBIG2 book · pages per second

pdfboss65.4
pypdfium257.4
pdfplumber56.5
PyMuPDF54.6

~14% ahead of the C-backed renderers, and the only one of the four with no C in it.

Every file in the rendering benchmark is certified before timing: pages reporting dropped or approximated content exclude their file, and an ink-coverage gate catches silently skipped work.

Markdown quality: opendataloader-bench, 200 PDFs
EngineReading-order NID ↑Total time
pdf-inspector0.9150.44 s
liteparse0.9130.75 s
opendataloader0.9022.57 s
pymupdf4llm0.88617.12 s
pdfboss md0.8820.15 s
markitdown0.84416.17 s

pdfboss md scores mid-field on quality and reads the whole corpus in about a seventh of a second, ~3× faster than the fastest competing Markdown engine.

Under the hood

Ten crates, one implementation.

No borrowed decoders. pdfboss ships its own JPEG 2000 (ITU-T T.800), JBIG2, CCITT and ICC codecs, an anti-aliased vector rasterizer, layout analysis to plain text and Markdown, async range-fetching I/O, a CLI and TUI, and PyO3 bindings.

Reporting

Rendering is lenient and it says so.

Broken files still open

Real-world PDFs are messy, so the reader is lenient by design: it reconstructs broken cross-reference tables, tolerates wrong stream lengths, and skips garbage operators instead of refusing the file.

Nothing is dropped silently

Content the renderer cannot read is skipped so the rest of the page still rasterizes, and every dropped or approximated item lands in a report: render warnings on stderr, render_reporting in Rust, Page.render_reporting() in Python.