pdf-inspector review: route PDFs before OCR

pdf-inspector is a fast local PDF parser and OCR router, not an OCR engine. Firecrawl's open-source Rust library classifies a document as text-based, scanned, image-based or mixed, extracts usable native text as Markdown, and returns the pages that still need OCR. That distinction is the product opportunity. A pipeline can stop paying the slowest, most expensive processing path for pages that already contain machine-readable text.

The viral claim says 0.002 seconds per page. The repository contains a strong benchmark, but not that exact universal promise. This review separates the measured result from the social post, explains where native parsing ends, and gives you a production decision framework for RAG ingestion, invoice extraction, legal-document search and AI-agent workflows.

What does pdf-inspector actually do?

It reads the PDF's internal structure before anyone renders a page or calls a model. The detector looks for text and image operators across the page tree. The extractor then reconstructs text with positions, font information, columns, links, lists, headings and tables. The result includes a confidence score, layout flags and a list of pages that need OCR.

The library does not include an OCR model. That is deliberate. The official pdf-inspector README describes a pure Rust parser with no ML model or external service. Firecrawl's hosted Fire-PDF pipeline is a broader product: it uses pdf-inspector for classification and native extraction, then applies layout detection and GLM-OCR to regions that need it. Do not evaluate one as if it were the other.

Does it really process 200 PDFs in 0.470 seconds?

Yes, in Firecrawl's published direct-text benchmark. No, that does not mean every PDF page finishes in two milliseconds.

The results were refreshed on 31 July 2026. They compare pdf-inspector 0.2.6 with LiteParse, OpenDataLoader, PyMuPDF4LLM and MarkItDown, with the full configuration and artifacts linked from the repository. The responsible buying conclusion is not "fastest PDF parser everywhere." It is "a promising local default for native-text PDFs that deserves a corpus-specific bake-off."

Firecrawl also says roughly 54% of the PDFs in its workload do not need OCR. Treat that as a vendor workload estimate, not a universal distribution. Run detection over your own last 30 to 90 days of documents before building the business case.

The production architecture: classify first, escalate second

1. Accept safely. Enforce file and page limits, verify the signature rather than trusting the MIME header, replace user-controlled filenames, and store uploads outside the web root.
2. Parse in isolation. Give the parser a CPU, memory and wall-clock budget. Treat every supplier PDF, email attachment and public upload as untrusted input.
3. Classify once. Record document type, confidence, page count, encoding warnings, complex-layout flags and pages needing OCR.
4. Use the cheap path. Convert high-confidence native text to Markdown without a network call.
5. Escalate narrowly. Render only flagged pages or regions and send those to the approved OCR service or local model.
6. Assemble with provenance. Merge results in original page order. Preserve page numbers, parser version, route, confidence and any human correction.
7. Gate the output. Check empty pages, character quality, table shape, totals, dates, identifiers and required fields before indexing or triggering an agent action.

This is where the savings come from. If a 100-page document has 82 usable native pages, the pipeline avoids 82 OCR-page calls. The planning formula is simple:

Estimated routing value = avoided OCR pages × marginal OCR-page cost, minus parser compute, engineering and correction cost.

Keep failed documents in the denominator. Our AI agent cost-per-action framework explains why a cheap extraction that later needs manual repair is not a successful action. For systems that index the Markdown, continue with the EU RAG production-readiness checklist. That page owns retrieval, permissions, evaluation and answer citations. This page owns the PDF ingestion route before chunking.

Node.js, Python, Rust or browser WebAssembly?

The official WebAssembly documentation says PDF bytes remain local, the build is single-threaded, CMaps are embedded, and image-only files still need a separate OCR step. That makes the browser version useful for privacy-sensitive preflight, but it does not turn the browser into a complete document-intelligence stack.

A Node.js route can stay small. The OCR and merge functions below are application code, not pdf-inspector APIs:

const result = classifyPdf(pdfBuffer)

if (result.pdfType === "TextBased" && result.confidence >= 0.9) {
  return processPdf(pdfBuffer).markdown
}

const native = processPdf(pdfBuffer).markdown
const scanned = await ocrOnly(pdfBuffer, result.pagesNeedingOcr)
return mergeByPage(native, scanned)

Do not hard-code 0.9 because it looks safe. Tune the threshold against false negatives, especially pages that appear to contain text but decode into noise. In invoice or legal workflows, one missed page can cost more than thousands of correctly avoided OCR calls.

Where pdf-inspector is a poor fit

• Scans, handwriting and photographs: it can route them, but it cannot read them without another OCR or vision component.
• Visual semantics that are not encoded as text: diagrams, checkboxes, signatures, stamps and spatial relationships may require layout or vision models.
• Perfect reconstruction: headings and tables are inferred from fonts, drawing operations and alignment. Heuristics can be wrong.
• Unbounded public uploads: Rust reduces some memory-safety risk, but a parser still needs limits, isolation and dependency updates. The project's security policy explicitly includes crafted-PDF memory and denial-of-service issues in scope.
• A zero-operations requirement: an open library gives you control, not a service-level agreement, review queue or automatic recovery.

OWASP's file-upload guidance recommends defense in depth: allowlisted types, signature checks, size limits, isolated storage, parser updates, malware scanning and sandboxing where available. Local processing can reduce data transfer. It does not make uploaded PDFs trustworthy.

Build, buy or run a hybrid PDF pipeline?

A ten-day evaluation before you commit

1. Sample reality: select at least 200 representative PDFs across languages, sources, page counts and failure cases. Keep a separate hostile and malformed set.
2. Label the route: mark which pages have reliable native text, need OCR, need layout processing or should be rejected.
3. Run a baseline: measure the current parser's quality, p50 and p95 latency, OCR pages, correction minutes and cost per accepted document.
4. Run pdf-inspector: pin the version and machine. Measure classification recall first, then Markdown structure and end-to-end throughput.
5. Price the exceptions: calculate avoided OCR pages, extra engineering, human repair and the cost of a missed scan.
6. Attack the boundary: test oversized, encrypted, malformed, misleading and resource-intensive PDFs in an isolated environment.
7. Choose with a gate: ship only if the hybrid route improves cost or latency without breaching the agreed extraction and safety thresholds.

If this becomes product infrastructure, use our AI enablement service to benchmark the corpus, build the routing layer and put evaluation around it. Twinsoft AI shows the same principle applied to production AI: quality gates and traceable evidence around model output. The MVP technology-selection guide helps decide which parts to own and which to buy before architecture hardens.

Primary sources and benchmark date

• Firecrawl pdf-inspector repository and benchmark, refreshed 31 July 2026.
• Official Node.js and Bun API documentation.
• Official Python API documentation.
• Official browser WebAssembly documentation.
• Firecrawl's Fire-PDF architecture announcement.
• OWASP File Upload Cheat Sheet.