Who pdf-inspector is for#
AI engineers building RAG systems or LLM document pipelines
pdf-inspector converts reports, research papers, and financial documents to clean, position-aware Markdown in under 200ms per document. The structured output preserves tables and headings, which reduces hallucinations in downstream LLM prompts and improves chunk quality for vector embeddings.
Skip if:
Your corpus is primarily scanned documents or image-heavy PDFs. Without the OCR runtime configured, pdf-inspector returns no Markdown for those documents.
Backend developers routing PDFs at scale
The classification API returns a PDF type and confidence score in 10-50ms, enabling pipelines to send only scanned pages to expensive OCR services. For a corpus where 54% of documents are text-based, this routing eliminates most OCR costs without sacrificing output quality on the remaining documents.
Skip if:
You need a fully managed API with no infrastructure setup. pdf-inspector is a library and CLI; it does not include a hosted API endpoint.
Data engineers extracting tables from financial documents
Dual-mode table detection (rectangle-based and heuristic) recovers financial tables, footnotes, and continuation tables across pages. The TEDS score of 0.814 on the benchmark corpus is the highest among the tested local parsers. Token-splitting handles consolidated numeric values common in financial filings.
Skip if:
Your financial documents are scanned PDFs without embedded text. The OCR runtime must be separately configured for those cases.
Web developers embedding PDF parsing in browser applications
The WebAssembly build runs the same Rust parser in browsers and Web Workers with no server round trip. Install via @firecrawl/pdf-inspector-wasm, call processPdf() with a Uint8Array, and get classification and Markdown output entirely client-side. PDF bytes never leave the user's browser tab.
Skip if:
Your users will upload scanned or image-heavy PDFs. The WASM build is pure extraction with no OCR capability.
The problem it solves#
Processing PDFs at scale has two expensive problems: OCR and output quality. Most document extraction services route every PDF through OCR regardless of whether it is actually scanned, because classification is a separate step most pipelines skip. For the roughly 54% of PDFs that are already text-based (reports, research papers, invoices, legal filings), this adds seconds of latency and unnecessary cost per document.
Output quality is the second problem. Raw PDF text extraction loses reading order, garbles multi-column layouts, misses tables, and fails on PDFs with CID-encoded fonts or complex formatting. The result is Markdown that needs extensive cleaning before it is usable in an LLM prompt or RAG index. Most open source parsers excel at either speed or output quality, but not both.
How it solves it#
Smart PDF classification
Detects whether a PDF is TextBased, Scanned, ImageBased, or Mixed by sampling content streams without a full document load. Returns a confidence score (0.0-1.0) and per-page OCR routing flags in 10-50ms, enabling downstream pipelines to skip OCR entirely for native-text documents.
Structured Markdown output with reading order
Reconstructs multi-column and newspaper layouts from positioned text, preserving logical reading order across the page. Output includes headings (H1-H4 via font size ratios), bullet and numbered lists, code blocks (monospace font detection), tables, bold/italic formatting, URL links, and page break markers.
Dual-mode table detection
Combines rectangle-based detection from PDF drawing operations with heuristic detection from text alignment. Handles financial tables with consolidated numeric values, footnotes, and continuation tables that span multiple pages. Benchmark table score: 0.814 TEDS on 200 real documents, the highest among the tested local parsers.
Selective OCR with per-page routing
Routes only pages that lack text operators to OCR rather than processing the whole document. Native Python and Node packages include the OCR integration using PP-OCRv6 Small locally. PDFium and ONNX Runtime are loaded only when a page is actually routed to OCR, keeping the default build lightweight.
npm, PyPI, crates.io, and CLI packages
The same Rust processing core is exposed through Node.js (npm, with TypeScript definitions), Python (PyPI), Rust (crates.io), and a bundled CLI. Every interface calls the same pipeline with the same output, so switching languages requires no retraining. The npm package includes the bundled pdf-inspector CLI.
Browser WebAssembly support
The Rust core compiles to WebAssembly and runs in browsers and Web Workers with no server round trip. Documents are processed locally using embedded CMaps, so PDF bytes never leave the browser tab. Install via the @firecrawl/pdf-inspector-wasm package on npm.
Strengths and trade-offs#
Strengths
- Fastest local parser in the opendataloader benchmarkOn 200 real PDFs, pdf-inspector completed the full corpus in 0.47s (median of 5 runs), compared to LiteParse at 0.75s, PyMuPDF4LLM at 17.1s, and MarkItDown at 16.2s. The Rust core loads each document once and shares parsed state across detection and extraction stages, avoiding redundant I/O.
- MIT license with no per-page billingThe MIT license allows commercial use, modification, and redistribution without restriction. Running locally means there is no per-page fee or API rate limit, which changes the economics of PDF processing at scale compared to Adobe PDF Extract API, Google Document AI, or Amazon Textract.
- Classifies 300-page PDFs in millisecondsThe classifier samples content streams without a full document load, detecting PDF type on even 300-page documents in milliseconds. The result includes a per-page list of pages needing OCR, enabling selective routing rather than all-or-nothing OCR decisions on mixed documents.
- Polyglot bindings sharing one Rust coreNode.js, Python, Rust, and browser environments all call the same underlying Rust pipeline. No binding-specific behavior differences to debug. TypeScript definitions are included in the npm package. The browser WASM build runs the same core with no server dependency.
Trade-offs
- -OCR requires separately installed runtime dependenciesSelective OCR is opt-in and requires PDFium and ONNX Runtime to be installed separately (platform-specific downloads, documented in the OCR runtime setup guide). The default build is pure extraction with no OCR capability. For purely scanned PDFs, the tool must be paired with an OCR service or the optional OCR feature.
- -No text output for scanned PDFs without OCR configuredPDF forms, image-based PDFs, and fully scanned documents produce no Markdown output without the OCR runtime enabled. Teams processing high-OCR corpora will need to configure the external dependencies or route those documents to a managed API like Reducto.
- -Benchmark limited to local, non-model-based parsersThe published benchmark covers only local engines without model-based PDF parsing, with OCR disabled. Scores are not directly comparable to managed services like LlamaParse or Adobe PDF Extract API that use LLM-based extraction. For scanned or image-heavy corpora, managed services may produce higher output quality.
pdf-inspector vs alternatives#
pdf-inspector vs LlamaParse (LlamaIndex)
LlamaParse is a hosted PDF parsing API designed for RAG and LLM pipelines. pdf-inspector is a local Rust library that solves the same problem for native-text PDFs without a server round trip.
| Feature | pdf-inspector | LlamaParse |
|---|---|---|
| License | MIT | Proprietary |
| Self-hosting | Yes | No (managed API) |
| Text-based PDFs | Under 200ms, local | API call required |
| Model-based extraction | No | Yes |
| OCR support | Selective, opt-in | Yes |
| Pricing | Free (self-hosted) | Usage-based |
For native-text PDFs, pdf-inspector is faster and cheaper: it classifies in 10-50ms and extracts locally in under 200ms with no API latency. LlamaParse routes every document through its hosted model, which adds network overhead for documents that do not need it. For scanned or complex PDFs where model-based extraction improves output quality, LlamaParse is the stronger choice.
pdf-inspector vs Adobe PDF Extract API
Adobe PDF Extract API is a managed service that extracts structured content from PDFs and charges per page with no self-hosting option. pdf-inspector targets the same native-text extraction use case but runs locally under an MIT license.
| Feature | pdf-inspector | Adobe PDF Extract API |
|---|---|---|
| License | MIT | Proprietary |
| Self-hosting | Yes | No |
| Output format | Markdown | JSON |
| OCR support | Selective, opt-in | Yes |
| Pricing | Free (self-hosted) | Per-page billing |
pdf-inspector is the better fit when you need local processing, Markdown output for LLM pipelines, or cost control on high-volume workloads. Adobe PDF Extract API is worth considering when you need its structured JSON output with figures and layout metadata, or when your corpus is predominantly scanned documents requiring managed OCR quality.
pdf-inspector vs Amazon Textract and Google Document AI
Amazon Textract and Google Document AI are both managed cloud APIs with OCR, forms extraction, and table detection. Like Adobe, they charge per page and require a network call for every document.
pdf-inspector is a better fit for the portion of your corpus that is already text-based: it processes those documents locally with no per-page charge and faster turnaround than a cloud API round trip. Both Textract and Document AI remain the stronger choice for scanned forms, handwriting recognition, or documents where cloud-grade OCR and structured entity extraction matter more than cost or latency.
Install and self-host#
Setup is available through npm, PyPI, and crates.io for Node.js, Python, and Rust respectively.
```bash
npm install @firecrawl/pdf-inspector
pip install pdf-inspector
cargo add pdf-inspector
```What it's built on#
- Languages
- PythonRust
- Runtimes
- Node.js
FAQ#
Does pdf-inspector handle scanned PDFs?
Yes, with the OCR integration enabled. The default build is pure extraction for native-text PDFs. Native Python and Node packages include selective OCR using PP-OCRv6 Small locally, but PDFium and ONNX Runtime must be installed separately. The CLI and Rust crate opt into OCR at build time via a feature flag. For fully scanned corpora, a managed OCR service may be simpler to set up.
How does pdf-inspector compare to LlamaParse for text-based PDFs?
pdf-inspector runs locally in under 200ms per document with no API call required for text-based PDFs, while LlamaParse is a managed API that routes all documents through its hosted service. For native-text PDFs (reports, papers, invoices), pdf-inspector eliminates the API latency, network cost, and per-page fee. LlamaParse may still be preferred for scanned or complex documents where its model-based extraction produces better results.
What languages and runtimes does pdf-inspector support?
pdf-inspector ships bindings for Node.js (via npm, with TypeScript definitions), Python (via PyPI), and Rust (via crates.io). A bundled CLI is included with the npm package. A separate WebAssembly package (@firecrawl/pdf-inspector-wasm) runs the same parser in browsers and Web Workers with no server dependency.
Is pdf-inspector free to use commercially?
Yes. The MIT license allows commercial use, modification, and redistribution without restriction. There are no per-page fees or rate limits when running locally. The only cost is your own infrastructure.
How accurate is the PDF-to-Markdown conversion?
On the opendataloader-bench corpus of 200 PDFs (results refreshed July 31, 2026), pdf-inspector scored 0.875 overall, 0.915 on reading order, and 0.814 on table structure, the highest scores among local parsers tested without OCR. These scores apply to native-text PDFs; scanned and image-based PDFs require the OCR integration to produce any Markdown output.
Similar open-source tools#
MarkItDown
Convert PDFs, Office files, and images to Markdown, free
crawl4ai
LLM-ready web crawling without API keys or rate limits
deer-flow
Build super agents with DeerFlow's powerful framework
monocode
One desktop UI for all your AI coding agents.
googletest
C++ testing and mocking framework by Google
browser-use
Python library giving any LLM full browser control, MIT licensed