pdf-inspector is a fast Rust library for classifying PDF files and pulling structured text out of them before any OCR service is involved. It was built by Firecrawl for the common situation in a document pipeline: every incoming PDF is shipped off to an expensive OCR endpoint, even though a large share of those files already carry a real, machine-readable text layer. The project's own figure is that roughly 54% of PDFs do not need OCR at all. It is aimed at developers building ingestion and indexing pipelines — search, retrieval, data extraction — who care about cost per page and about latency.
What it does
The library has two jobs, and the first one is the interesting one. Given a PDF, it decides what kind of document it is: TextBased, Scanned, ImageBased, or Mixed. It returns a confidence score between 0.0 and 1.0 along with per-page OCR routing, so a mixed file — a typed report with a few scanned exhibits stapled in — can send only the pages that actually need it to an OCR service.
The second job is extraction. When the text is there, pdf-inspector reads it with position awareness: font information, X/Y coordinates, and automatic reading order for multi-column layouts. On top of that sits a Markdown converter that tries to preserve structure rather than dump a wall of characters:
- Headings H1 through H4, inferred from font size ratios
- Bullet, numbered, and lettered lists
- Code blocks, detected from monospace fonts
- Tables, both rectangle-based and heuristic
- Bold and italic formatting, URL linking, and page breaks
Table handling is the part most parsers get wrong, and here it runs in two modes: rectangles read from the PDF's own drawing operations, plus a heuristic pass over text alignment for tables drawn with whitespace instead of rules. The README says this covers financial tables, footnotes, and tables that continue across pages.
There is also real attention to text encoding — ToUnicode CMap decoding for Type0 and Identity-H CID fonts, UTF-16BE, UTF-8 and Latin-1 — plus detection of newspaper-style columns and right-to-left text.
How it works
Classification is cheap because it does not parse the whole document. It samples content streams, which the README puts at roughly 10-50ms per file. Extraction and Markdown conversion then run locally; Firecrawl's stated target is handling a text-based PDF end to end in under 200ms, with no network call and no OCR bill.
Worth knowing before you plan around it: OCR itself is opt-in and is available to native Rust and CLI consumers. The default path, and what the language bindings give you, is classification plus no-OCR extraction. The library's role in a scanned-heavy pipeline is to be the router in front of whatever OCR you already use, not to replace it.
The video's demo cites numbers beyond the README — about 36x faster than a typical OCR pipeline, a higher score than every rival parser tested, and a full benchmark run in under half a second. Those are the project's own benchmark claims; the methodology is not in the materials here, so treat them as a reason to run your own corpus through it rather than as a settled result.
Getting started
It is published everywhere you would want it. The Rust crate is on crates.io as pdf-inspector, the Node.js package is @firecrawl/pdf-inspector on npm, and the Python package is pdf-inspector on PyPI. There is also a browser WebAssembly build, which means classification and text extraction can happen client-side without uploading the document anywhere. Per-language docs live under docs/python.md, napi/README.md and wasm/README.md in the repository. The license is MIT.
When to use it / when not
Use it when volume or mixed input makes blanket OCR wasteful: a crawler or ingestion service taking arbitrary PDFs, a RAG indexer that needs clean Markdown, a browser or on-device flow where the file should not leave the machine, or a cost-reduction pass in front of an existing OCR vendor.
Skip it when your corpus is genuinely all scans or photographed pages — the classifier will correctly tell you so, but from a binding you would still route everything onward, and the win disappears. It is also a library, not a service or a GUI: you are writing code around it. And if your requirement is faithful visual layout reconstruction rather than readable structured text, Markdown is the wrong target format regardless of how good the parser is.
Anyone running PDFs through an OCR API at scale should take this seriously, and the cheapest way to evaluate it is to classify a sample of real production files and see what fraction comes back TextBased. The project is young — created in early 2026 — but it has drawn well over 18,000 stars, ships under MIT, and is maintained by a company whose own product depends on it. A ~50ms check that can remove a paid network round trip from half your documents is an unusually easy thing to justify.