PDF Oxide

Pulling clean text out of PDFs is one of the dullest and most frustrating jobs in software, yet it sits at the entry of nearly every document pipeline and RAG system. The format was designed for printing, not parsing, so layout, fonts, and reading order have to be reconstructed after the fact. The popular answers in this space have long been Python libraries such as PyMuPDF and pypdf, which are capable but tie you to one language and can become a bottleneck at scale. PDF Oxide, by yfedoseev, tackles the problem from a different angle: it is a Rust-native PDF library that handles text and image extraction, markdown and HTML conversion, plus creation, editing, merging, splitting, watermarking, and form fields, all from a single core.

The distinctive idea is one engine, many front doors. The performance-sensitive work lives in a Rust core, and that core is exposed through bindings for Python, Go, JavaScript and TypeScript, .NET, Java and Kotlin, and WebAssembly, alongside a CLI and a Model Context Protocol server. Because every language calls the same compiled code, behaviour stays consistent whether you run it from a Python notebook, a Go service, or the browser via WASM, and there are no subprocess calls or external runtimes. The project reports a mean of 0.8ms per document and claims 5 to 29x faster results than common Python libraries, validated across 3,830 test PDFs drawn from veraPDF, Mozilla pdf.js, and DARPA SafeDocs corpora with what it describes as a 100% pass rate.

The natural audience is teams building document-ingestion pipelines, especially for retrieval-augmented generation, where extraction speed and predictable output across services matter. A Python data team can prototype extraction in a notebook, then ship the identical logic inside a Go or .NET backend without rewriting parsing rules. The bundled MCP server is the most immediately useful on-ramp: it lets assistants like Claude, Cursor, or Claude Code read PDF contents locally, with no files leaving the machine, which is attractive for sensitive documents. The WASM build opens client-side extraction in the browser, and the creation and forms features mean it can also sit on the output side of a workflow, generating PDFs from markdown or HTML rather than only consuming them.

The honest caveats are real. The star count is modest relative to the breadth of the project, so the community, third-party tooling, and long-term maintenance commitment are less proven than the incumbents. The speed and parity figures are self-reported, with no independent benchmark linked, so treat the 5 to 29x and 99.5% parity claims as the project's own numbers until reproduced. The README leans heavily on benchmarks and lists no limitations, which is itself a yellow flag: markdown quality on complex multi-column layouts and dense tables is not demonstrated, and that is exactly where extractors tend to fail. There is no OCR, so scanned or image-only PDFs are out of scope. Seven bindings from a small team also means a wide surface to keep in sync.

Against commercial options like LlamaParse or AWS Textract, PDF Oxide plays a different game. Those services are managed, include OCR, and are tuned for messy real-world scans, but they send your documents to a vendor and bill per page. PDF Oxide is local, free under MIT or Apache-2.0, fast, and language-agnostic, which is compelling when your PDFs are born-digital and privacy or cost rules out an external API. It is worth adopting now if you are building a RAG ingestion layer over clean, machine-generated PDFs and value multi-language consistency and the MCP integration. It is too early if you depend on battle-tested handling of malformed or scanned files, where PyMuPDF's larger edge-case community, or a service with OCR, remains the safer bet.