// the find
yfedoseev/pdf_oxide
The fastest PDF library for Python and Rust. Text extraction, image extraction, markdown conversion, PDF creation & editing. 0.8ms mean, 5× faster than industry leaders, 100% pass rate on 3,830 PDFs. MIT/Apache-2.0.
A Rust-core PDF library (text extraction, image extraction, markdown conversion, PDF creation and editing) with bindings for 19 languages via a C ABI layer. The main pitch is MIT licensing as a PyMuPDF drop-in replacement — PyMuPDF is AGPL, which quietly blocks commercial use for a lot of teams.
- The license argument is real. PyMuPDF's AGPL is a genuine problem for commercial projects, and this fills that gap with MIT/Apache-2.0 dual licensing.
- Using a stable C ABI as the bridge for all language bindings is the right call architecturally — one core fix propagates everywhere instead of 19 independent rewrites.
- The benchmark methodology is reproducible: public corpora (veraPDF, Mozilla pdf.js, SafeDocs), specific timeouts, single-threaded, stated methodology. You can reproduce it.
- CI workflows are per-binding (separate `.github/workflows/` files for Clojure, Dart, Elixir, Kotlin, etc.), so a broken binding fails its own pipeline rather than hiding behind a single green check.
- The velocity is the first thing to interrogate. Eleven new language bindings in a single release (v0.3.69), `.devin/wiki.json` in the repo root, and `AGENTS.md` all point to Devin or similar AI agents doing the bulk of the implementation work. PDF parsing is a domain where subtle correctness bugs — wrong codepoint mappings, broken xref recovery, malformed stream handling — show up months later in production, not in a test suite built over the same weekend.
- The headline '100% pass rate on 3,830 PDFs' conflicts with the fine print: the Mozilla pdf.js corpus shows 99.2%, not 100%. The 7 non-passing files are called 'intentionally broken' but the veraPDF corpus is specifically designed to stress conformance, and real-world PDFs are not from these test suites.
- Nineteen language bindings is a massive ongoing maintenance surface. Each binding needs platform-specific native library bundling, packaging for each ecosystem's registry, and someone to respond to issues. Even with AI tooling, a single-person project supporting Zig, Clojure, Objective-C, R, and Julia simultaneously is a pattern that tends to go quiet when the initial publicity wave passes.
- No OCR support for scanned PDFs despite the `.models/` directory containing what look like PaddleOCR model files — the README lists it as a separate paid/enterprise feature, which means a significant class of real-world PDFs (anything that went through a scanner or was exported from image-based tools) are out of scope for the benchmarks and potentially for the library itself.