lopdf vs pdfium in Rust — What I Learned Building a PDF App

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

I built Hiyoko PDF Vault — a macOS PDF tool — in Rust. Choosing the right PDF library was the first real decision. lopdf or pdfium. Here's what I found.

lopdf: pure Rust, no dependencies

lopdf is pure Rust. No C bindings, no system libraries, no bundling headaches.

What it does well:

• Merge, split, rotate pages


• Read and write PDF structure


• Metadata manipulation


• Bates numbering


• Works well for structural PDF operations

What it struggles with:

• Rendering PDFs to images (not its job)


• Complex font handling


• Malformed PDFs — lopdf is strict; real-world PDFs often aren't

For a tool that manipulates PDF structure without rendering — merge, split, encrypt, add watermarks, strip metadata — lopdf is the right choice. Pure Rust means easy cross-compilation and universal binaries with no extra work.

pdfium: full rendering, C dependency

pdfium is Google's PDF engine (from Chromium). The pdfium-render crate wraps it for Rust.

What it does well:

• Accurate PDF rendering to images


• Handles malformed PDFs that lopdf rejects


• Text extraction from complex layouts


• Full PDF spec compliance

What it requires:

• Bundling the pdfium binary with your app (~20MB)


• Architecture-specific binaries (x86_64 and aarch64 for universal binary)


• More complex build setup

For a tool that needs to display PDFs or extract text from complex documents, pdfium is the right choice. You pay for it in bundle size and build complexity.

What I actually use

lopdf for structural operations: merge, split, encrypt, watermark, metadata, Bates numbering.

Apple Vision Framework (via Tauri shell commands) for OCR — it's already on the user's Mac and handles Japanese text better than anything I could bundle.

I avoided pdfium because the bundle size increase wasn't worth it for my use case. If I needed accurate rendering, that calculation would change.

The honest recommendation

Start with lopdf. It covers most PDF manipulation use cases with zero dependency overhead. Add pdfium only if you need rendering or encounter malformed PDFs that lopdf rejects. The complexity is justified for those use cases — not for most others.

TL;DR: lopdf = pure Rust, zero deps, great for structural ops (merge/split/encrypt/watermark). pdfium = accurate rendering + malformed PDF handling, but adds ~20MB and C bindings. Start with lopdf. Only add pdfium if you need rendering or hit lopdf's strict parser limits.

If this was useful, a ❤️ helps more than you'd think — thanks!

Hiyoko PDF Vault | X → @hiyoyok