Why We Switched file2markdown's PDF Engine to pdf-inspector (With Benchmarks)
Why We Switched file2markdown's PDF Engine to pdf-inspector (With Benchmarks)
In August 2026 we replaced the PDF engine behind file2markdown's PDF converter. Text-based PDFs are now parsed by pdf-inspector, Firecrawl's open-source Rust library. This post shares the actual benchmarks that convinced us, and what changed for users — because we recommend conversion tools for a living, and we should show our homework when we switch our own.
What We Were Running Before
Our previous engine for text-based PDFs was a solid Java-based parser. It produced good structure, but carried three operational costs:
- JVM startup on every conversion — each request paid seconds of overhead before parsing began.
- Memory ceilings — very large or graphics-heavy PDFs could exhaust the Java heap, and we had dedicated error-handling just for that failure mode.
- Deployment weight — our container image shipped an entire Java runtime alongside our Python API.
None of these were dealbreakers. All of them disappeared at once.
The Benchmarks That Made the Decision
We tested pdf-inspector against our standing comparison corpus — an academic paper, an IRS form, a multi-column research paper, an invoice with tables, a technical spec, and a plain-text document — plus six real invoices from our own accounting folder (SaaS receipts, an ad-platform invoice, our own client invoice template).
Speed, per document (Apple Silicon, single run):
| Document | pdf-inspector | Notes |
|---|---|---|
| Academic paper (40k chars) | 61ms | 38 headings, 50 table rows detected |
| IRS form | 34ms | 30 headings, 52 table rows |
| Technical spec | 21ms | 38 headings |
| Invoice with tables | 1ms | Tables preserved as Markdown |
| Real invoices (6 documents) | 1–10ms each | Every field verified by hand |
For context, the same documents took seconds each through our previous JVM-based pipeline — and Python-based extractors we tested produced zero headings and zero Markdown tables on every one of these files (full analysis in pdf-inspector vs MarkItDown).
Accuracy on the real invoices: we diffed the Markdown against the source PDFs field by field — invoice numbers, dates, line items, totals, bank details. 100% of fields survived on all six documents. The one imperfection we found, and want to be honest about: multi-column headers can come out in slightly scrambled order (an address block merging into an adjacent table). No data is lost, but layout-sensitive documents are not pixel-faithful — our previous engine had the same class of issue.
What We Kept
pdf-inspector deliberately does no OCR, so our scanned-PDF path is unchanged: when its classifier (or ours) finds no text layer, we route the document to AI vision OCR instead. That hybrid — millisecond parsing for the ~half of PDFs with native text, real OCR for scans — is exactly the architecture pdf-inspector was designed to enable, and it is what you get on every conversion here.
Non-PDF formats (DOCX, PPTX, XLSX, EPUB, and the rest) are also unchanged.
What Users Notice
- Text-based PDF conversions return near-instantly — the engine now parses in milliseconds; total time is dominated by your upload speed.
- Large PDFs that previously hit memory errors convert normally.
- Output structure is at parity or better: more headings detected on technical documents, tables preserved as real Markdown tables.
Should You Use pdf-inspector Directly?
If you are a developer building your own pipeline: quite possibly — it is MIT-licensed and excellent. Start with our plain-English guide to pdf-inspector, then the comparisons against Docling and Marker to understand where it stops (OCR, complex multi-column layouts).
If you just want clean Markdown from any document without integrating anything: that is what we are for — the same engine, plus OCR, every other format, and an API.
The Markdown Memo
A fortnightly note for lawyers, researchers, accountants, and anyone else drowning in PDFs, scans, and decks. No spam.