pdf-inspector: A PDF Classification OCR Library for Cleaner Extraction Pipelines
Firecrawl's open-source Rust library classifies a PDF as text-based or scanned in milliseconds, then routes it to local extraction or OCR automatically. Here is what it does, what its own benchmark actually shows, and who has the technical bar to use it.
Most document pipelines waste money on OCR they do not need. A PDF classification OCR library is the piece that decides, before any expensive processing starts, whether a file even needs OCR at all. pdf-inspector, an open-source Rust library from Firecrawl, does exactly that: it looks at a PDF, decides in milliseconds whether it is text-based, scanned, image-based, or mixed, then routes it to fast local text extraction or hands it off to OCR. As of today, the GitHub repository sits at 14,983 stars and 1,033 forks. At launch, Firecrawl's own announcement post drew 4,276 likes and 247 reposts.
What pdf-inspector actually does
The library has two jobs, and it is worth separating them clearly because the marketing around "PDF AI tools" tends to blur them.
First, classification. pdf-inspector parses a PDF's xref table and page tree without loading the full document, then scans pages for text operators versus image operators. Firecrawl's documentation puts this at roughly 10 to 50 milliseconds depending on scan strategy, and the output is not just a label. It returns a confidence score and a list of the specific pages that need OCR, so a caller can route page by page instead of treating a 40-page mixed document as all-or-nothing.
Second, extraction. For PDFs it classifies as text-based, pdf-inspector extracts the text itself, position-aware, with font metadata, multi-column reading order, and conversion straight to Markdown, including heading levels, lists, and tables. Firecrawl's own numbers put local extraction at around 150 milliseconds per document once classification has cleared it. What the library does not do is OCR. Scanned and image-based pages get flagged and pointed elsewhere; there is no bundled OCR engine here.
The benchmark, read carefully
Firecrawl publishes benchmark results against the opendataloader-bench corpus, 200 PDFs, scored on reading order, table accuracy, and heading detection, with OCR disabled so the comparison is apples to apples between local, non-OCR parsers. In the most recent published run, pdf-inspector posted the highest overall score (0.875) and the fastest complete run on all 200 documents (0.470 seconds), narrowly ahead of a parser called LiteParse on overall score and well ahead of pymupdf4llm and markitdown on speed.
That is a real result, but scope it correctly: this benchmark only covers PDFs that do not need OCR. It says nothing about scanned-document accuracy, because pdf-inspector is not competing in that category. It is a claim about how fast and how structurally accurate it is at the extraction it actually performs, not a claim about universal document handling.
Fitting it into an extraction pipeline
The intended use case, per Firecrawl's own README, is a two-step gate: pdf-inspector classifies a PDF in around 20 milliseconds, and if it comes back text-based with high confidence, extraction happens locally in roughly 150 milliseconds, no network round trip, no OCR bill. If it does not clear that bar, the file goes to an OCR service. For a pipeline processing invoices, contracts, financial reports, or research papers at volume, this is the difference between paying for OCR on every file and paying for it only on the roughly half that actually need it.
For anyone feeding PDFs into an LLM or an agent, this matters beyond cost. A PDF that silently fails extraction, or gets OCR'd into garbled text, poisons whatever runs downstream of it. Sorting scanned from text-based before extraction is a small step that prevents a large class of quiet failures.
pdf-inspector vs anydoc: two different Firecrawl tools
Firecrawl ships more than one document tool, and it is worth being precise about which is which, since both come from the same maker and cover adjacent ground. pdf-inspector is narrow and fast: a Rust library purpose-built to classify scanned versus text-based PDFs and route them accordingly, with its own local Markdown conversion for the text-based case. anydoc is a separate, newer Firecrawl tool aimed at a broader job, parsing PDFs, Word documents, and slide decks into Markdown as a general document converter. They are not the same product wearing two names. pdf-inspector's whole reason to exist is the classification-and-routing decision at the front of a pipeline; anydoc's is format coverage across document types. A pipeline could reasonably use both: pdf-inspector to gate PDFs before extraction, anydoc where a wider range of file formats needs converting.
Who this is actually for
This is a developer library, not a hosted product. There is no dashboard, no API key, no drag-and-drop uploader. Using it means installing a package, Python via pip install maturin and a maturin develop --release build step, Node via npm install @firecrawl/pdf-inspector, or Rust via cargo add pdf-inspector, and calling it from code as part of a larger document pipeline. There is also a CLI (pdf2md, detect-pdf) for anyone who wants to test it against a single file before wiring it into anything.
It fits teams already building or maintaining a document ingestion pipeline who want to cut OCR spend and stop wasting time on PDFs that do not need it. It is not a fit for someone who wants to drop a single PDF into a tool and get a clean file back with zero setup. For that, a hosted parser or Firecrawl's own broader tools, including anydoc, are the more sensible starting point.
Limitations worth knowing before adopting
The library has no bundled ML model and does not do OCR itself, so a pipeline still needs a separate OCR service for the scanned half of its documents. Table and layout detection, while benchmarked well against comparable local parsers, is heuristic and font-based rather than model-based, so unusual PDF structures (heavily nested tables, non-standard fonts, some scanned documents that partially embed a text layer) can still trip it up. It is also young: the repository was created in February 2026, is under active development, and carries 147 open issues at last check, worth a skim before betting a production pipeline on it.
Getting started
The fastest way to evaluate fit is the CLI against a real sample of the documents a pipeline actually receives: detect-pdf document.pdf --json to see the classification and confidence score, then pdf2md document.pdf to see what the Markdown output looks like on a genuine text-based file from that document set. That fifteen-minute test answers the only question that matters here: whether this particular library's classification threshold and Markdown conversion match a specific pipeline's PDFs, before any code gets written around it.
Join the newsletter
AI workflows and systems, straight to your inbox.
No spam. Unsubscribe anytime.