Firecrawl's PDF Inspector gained 589 GitHub stars in a single day because it addresses an unglamorous decision that slows document pipelines: whether a page contains usable text or needs OCR. The MIT-licensed Rust project classifies that before extraction, then returns the page numbers that need OCR. That moves an expensive choice from a whole-document guess to a per-page routing result. The repository had 18,361 stars and 1,242 forks when MrKeyoor checked it on September 2.
The surge is attached to a project that has been shipping quickly rather than a one-day prototype. Version 1.17.0 reached PyPI and npm on August 21. The latest formal GitHub release remains version 1.15.0, published four days earlier, so the registries are ahead of the repository's release page.
The costly branch before parsing
A PDF page may hold real text operators, a full-page image, or some of both. Sending every page through OCR adds seconds and external runtime requirements, while treating every page as native text can return an empty or mangled result. PDF Inspector's documented pipeline assigns one of four types: TextBased, Scanned, ImageBased, or Mixed. It also returns a confidence score and the exact pages it thinks should take the OCR path.
The classification notes say the first pass reads the cross-reference table and page tree, then examines PDF content streams for Tj and TJ text operators and Do image operators. The default strategy checks pages until it finds a non-text page. A full mode scans the entire file, a sampling mode spreads checks through a large document, and callers can provide specific page numbers. Those choices let a service trade a little classification work for a better view of mixed documents.
Classification is only the front of the pipeline. According to the project's extraction architecture, the parser records font data and coordinates, arranges text into reading order, detects columns and tables, and emits Markdown. It also handles CID fonts, right-to-left text, headings, lists, links, and code blocks through font and geometry rules. These are structural heuristics. Open bug reports show that a page can contain valid text operators while the resulting order or character decoding is still wrong.
The detector and extractor share one document load rather than parsing the same file twice. Positioned-item output can preserve coordinates and font metadata, while CLI flags can select pages, retain page markers, or collapse long dot leaders in the --compact form. That gives batch jobs a choice between plain Markdown and richer machine-readable output without inserting another PDF library into the route.
A small command sits before the expensive path
Developers can put the classifier in a shell pipeline without adopting Firecrawl's hosted service. The project's CLI instructions expose detection separately from conversion, and JSON output makes the result usable by another process:
cargo install pdf-inspector
detect-pdf document.pdf --json
pdf2md document.pdf --compact
The default Rust build performs native extraction without loading an OCR model. Python and Node packages expose selective OCR, while Rust and CLI users enable the ocr feature. Browser WebAssembly runs the Rust parser locally with embedded character maps and no server round trip, although the browser build remains on the pure extraction path. Our review of PDF Inspector covers the setup reality for developers comparing these entry points.
OCR has a larger operational footprint than the short API suggests. Firecrawl's runtime guide specifies PDFium, ONNX Runtime, and a pinned PP-OCRv6 Small model set. The first routed page downloads and verifies about 31 MB across three artifacts. Clean native-text documents do not touch those libraries, the model cache, or the network. Teams with sealed deployments can prefill the cache and require offline mode.
That boundary is the project's most useful design choice. A 40-page report with one scanned signature page does not need 40 OCR passes. The classifier can extract the native pages and route the outlier. The OCR result contract retains per-page provenance and names pages whose local output is empty, low-confidence, or incomplete enough to recommend another parser. Setup failures are returned as errors instead, allowing an integration to separate a broken runtime from a weak recognition result.
Firecrawl's benchmark needs the fine print
In its benchmark table, Firecrawl reports an overall score of 0.875 on a 200-document OpenDataLoader corpus, with 0.915 for reading order and 0.814 for tables. Its recorded complete run took 0.470 seconds. LiteParse, the nearest result in the table, scored 0.873 overall and took 0.750 seconds. The other listed parsers finished farther behind on either quality, time, or both.
The comparison is Firecrawl's own, and its published protocol matters as much as the headline numbers. It used an Apple M4 Pro, disabled OCR, processed each document sequentially, and reported the median of five corpus runs after a warm-up. Firecrawl also published the parser versions, predictions, evaluator output, charts, and a paired harness that fails when a candidate build regresses against its baseline. That makes the claim inspectable, though it does not make it independent.
There is another timing caveat. The July 31 protocol tested PDF Inspector 0.2.6, while today's Python and Node packages are 1.17.0. The results describe an older parser on one corpus and one machine. They support a serious performance claim for native-text extraction, but they do not measure current selective OCR, hostile inputs, or the unusual layouts represented in the project's open issues.
The issue tracker shows where PDFs fight back
Recent reports describe near-duplicate pages being dropped, sparse two-column text merging across a wide gutter, and vertical Japanese text being reversed or mistaken for a table. Another open issue says some Type0 fonts with a ToUnicode map decode individual characters incorrectly. These failures are easy to miss in a pipeline because the output may look structured while carrying the wrong order or characters.
OCR routing has its own edge cases. The tracker records scans with invisible text layers that can be classified as image-only, and partially garbled OCR pages that report high confidence without a hosted-parser recommendation. Pull requests opened this week target some of those cases, along with missing bullet glyphs, malformed cross-reference tables, and sparse column detection. Maintainers are reviewing patches, but teams still need to test the parser against their own troublesome documents before replacing an existing route.
A September 1 main-branch commit also tightened resource limits after a 21 MB tagged PDF expanded an object stream to roughly 1.5 GB in memory. The patch moved to lopdf 0.44 and capped decompression at 8 MB per object stream. Because the published 1.17.0 packages predate that commit, users handling untrusted uploads should check the exact package revision rather than assuming the fix is already in their registry install.
Where the project fits
The project's published use case is a local preflight and extraction stage. Native-text reports can become Markdown quickly, mixed files can take a page-specific OCR route, and browser applications can parse supported documents without uploading them for that step. The returned page list is also useful for systems that already have an OCR provider and only need a cheaper way to decide when to call it.
It is less settled as a single answer for arbitrary public uploads. The latest CI configuration runs the full OCR runtime smoke test on Linux x64. macOS and Windows compile and run platform-independent OCR tests, while their external-runtime paths remain preview paths in the project's own guide. A service that accepts unknown PDFs still needs memory limits, process isolation, timeouts, and output checks around the parser.
The next registry release will show whether the object-stream decompression bound reaches normal installs. Fixes for the current decoding and reading-order reports, plus full OCR runtime smoke tests beyond Linux x64, would close two other visible gaps. A new benchmark run on the 1.17 series should measure selective OCR separately. Until then, the 589-star day points to real demand for smarter PDF routing, while the repository supplies the reasons to evaluate it with difficult files before deployment.