Stop OCRing Every PDF: Route It First with pdf-inspector

OCR is often the most expensive and slowest step in a document-ingestion pipeline. The frustrating part is that many PDFs already contain usable text, yet a naive pipeline sends every document through OCR anyway.

pdf-inspector takes a better approach: classify first, extract native text when possible, and route only the pages that actually need OCR.

The core decision is simple:

PDF arrives
  ↓
Classify the document and its pages
  ├─ native text available → extract locally → Markdown
  └─ text missing/broken   → route those pages to OCR

That small decision can remove a large amount of unnecessary OCR work from RAG ingestion, invoice processing, research-paper parsing, and document search.

The library classifies PDFs as:

TextBased

Scanned

ImageBased

Mixed

It also returns a confidence score and the specific pages that need OCR. A 40-page report with one scanned appendix does not have to become a 40-page OCR job.

Install the package:

pip install pdf-inspector

Then process a PDF:

import pdf_inspector

result = pdf_inspector.process_pdf("document.pdf")

print(result.pdf_type)
print(result.pages_needing_ocr)
print(result.markdown)

For selective OCR, the native package also exposes an OCR-aware pipeline:

ocr_result = pdf_inspector.process_pdf_with_ocr("document.pdf")
print(ocr_result.pages_routed_to_ocr)

The OCR runtime remains separate and is only touched when a page is routed to it. That keeps the default extraction path lightweight.

The same idea is available for Node.js:

npm install @firecrawl/pdf-inspector
js
import { readFileSync } from "fs";
import { processPdf } from "@firecrawl/pdf-inspector";

const pdf = readFileSync("document.pdf");
const result = processPdf(pdf);

console.log(result.pdfType);
console.log(result.markdown);

There is also a WebAssembly package for running the Rust parser locally in a browser or Web Worker:

npm install @firecrawl/pdf-inspector-wasm

This is useful when documents should not be uploaded to a parsing service just to determine whether they contain native text.

Classification is only half the project. For text-based PDFs, the extractor attempts to preserve structure such as:

The output is Markdown, which makes the library convenient for search indexing and LLM/RAG pipelines.

At a high level, the detector inspects PDF content streams for text operators such as Tj

and TJ

, and image operators such as Do

. It can scan all pages, stop early, sample a large document, or inspect a caller-provided page set.

This is a routing signal, not a promise that every PDF will be perfectly parsed. PDFs with broken encodings, text converted to vector paths, or extremely complex layouts may still need OCR or a specialized parser. The library explicitly reports encoding problems so callers can fall back instead of silently accepting bad text.

The project publishes a reproducible benchmark against a 200-document corpus. Its July 2026 results report strong reading-order and table scores as well as fast local processing. Those are project-published measurements on specified hardware—not a universal latency guarantee—so benchmark your own document mix before committing to production thresholds.

The more durable takeaway is architectural: OCR should be a fallback chosen per page, not the default chosen per file.

A conservative router might look like this:

result = pdf_inspector.process_pdf("document.pdf")

if result.pdf_type == "text_based" and result.confidence >= 0.95:
    store_markdown(result.markdown)
else:
    send_pages_to_ocr(result.pages_needing_ocr)

Your threshold should depend on the cost of a false positive. A casual knowledge base can tolerate more extraction noise than a legal or financial workflow.

If your pipeline currently OCRs every incoming PDF, classification-first routing is a small change with a clear operational payoff.

The longer version and implementation notes are available on ToolGenix.