August 29, 2026

Testing pdf-inspector's claims against PDFs I made up

pdf-inspector (Firecrawl, MIT, Rust core with a pip install pdf-inspector Python binding) claims it can look at a PDF and tell you, in ~10-50ms, whether it's text-based, scanned, or a mix of both — so a pipeline can route only the scanned pages to OCR instead of running every page through it. It also claims it can convert the text-based pages straight to Markdown, tables and all.

To check the first claim, I needed three kinds of PDF and a ground truth for each: one that's real, extractable text; one that's a flat scanned image with no text layer at all; one that's both, mixed across pages. I built all three myself with PyMuPDF rather than use a real document, so I'd know the correct answer for every page before running the tool — no paid API, no external service, everything below ran locally. Here's what pdf-inspector said, against what I already knew was true:

All three came back correct, and on the mixed PDF it also correctly flagged only the scanned page for OCR — that combination (right label, right page-level routing) is the specific thing the tool is claiming to do, so this is the result that matters most in this post.

What I ran

The classification and routing claims hold up exactly as documented. The Markdown conversion is where it gets uneven.

What the conversion dropped

The source table (real cell data, aligned columns, no visible borders since my PDF generator draws borders as plain positioning, not vector lines) came out as this:

### Metric Q1 Q2 Delta

Orders shipped 82,410 91,205 +10.7% Refund rate 2.4% 2.1%-0.3pp Unmapped SKUs 1,204 883-26.7%

Not a table. The header row became a heading, the three data rows ran together into one paragraph with no separators. pages_with_tables came back empty for a page that has a real table. The README documents two detection paths, rectangle-based and alignment-based; the rectangle path needs actual drawn border lines, which my source PDF doesn't have, so that one not firing is explainable. The alignment-based path is specifically supposed to catch a borderless-but-aligned table like this one, and it didn't.

Three smaller drops in the same page: one of my two <h3> headings ("Fulfillment") converted, the other got merged into the end of the preceding paragraph as bold text instead of its own heading, with no visible difference between the two in the source HTML. A <sup>1</sup> footnote marker came out as report1., no space, no bracket, nothing marking it as a footnote. And the one hyperlink in the document, <a href="...">the pdf-inspector repo</a>, was converted to plain text, the link itself simply gone, despite "URLs converted to Markdown links" being a documented feature.

Thoughts

The two things this tool is actually named for, classifying pages and routing only the ones that need OCR, work exactly as claimed, and the 56ms processing time makes the "save cost/time" pitch real rather than aspirational. I'd trust it for that today.

I would not yet trust the Markdown conversion unattended on anything beyond plain paragraphs and simple lists. Four separate features that are explicitly documented, tables, one of two identically-styled headings, superscripts, and links, didn't survive the trip on a single one-page test file. That's not "occasionally imperfect," that's most of the structured content on the page.

Appendix: building the test PDFs