pdf-inspector and the ten-cent invoice

The person at your company who opens supplier invoices out of an inbox and keys the numbers into the accounting system is doing work that Google will sell you by the piece, at ten cents a document for its invoice parser and thirty dollars per thousand pages for the generic form parser that reads everything else. Those two numbers are the reason the automated version of that job has always been quoted to you as a meter rather than a purchase. Yesterday's commits landed on pdf-inspector, the MIT-licensed Rust library Firecrawl published to decide, in about twenty milliseconds and for nothing, which of your documents need to be put on that meter in the first place. By Firecrawl's own count, roughly 54 percent of PDFs never did.

That is a routing story, not a parsing story, and routing is the part nobody quotes you for.

What it actually does, and what it refuses to do

pdf-inspector reads the inside of a PDF instead of looking at the outside of one. Font encodings, text operators, how much of the page is covered by an image. From that it decides whether what you handed it is TextBased, Scanned, ImageBased or Mixed, gives you a confidence score, and marks page by page whether an eye is required. The classification takes ten to fifty milliseconds. There is no model, no GPU, no network call and no account.

When the page turns out to be text based, and this is the useful half, it pulls that text out with position awareness and writes GitHub-flavored Markdown: headings inferred from font size ratios, tables detected both by drawn rectangles and by column alignment, reading order reconstructed across multi-column layouts, bold and italic preserved. A text-based PDF comes back in under two hundred milliseconds on a laptop.

What it will not do is optical character recognition. It does not look at pictures of words. Point it at a photograph of a delivery ticket and it will tell you, correctly and quickly, that it cannot help and that this one is going to cost you. That refusal is the product.

The traction is real and it is recent. Around 14,200 stars and 962 forks, of which roughly 8,600 stars arrived in the past week, which puts it at the top of the weekly trending board. The npm package has been published since April 17 and is on its fifty-first version. There are no tagged GitHub releases at all, which matters if your habit is to pin to a release; you pin to a package version here instead. And the commit log is not decorative. The four most recent commits, all from yesterday, are a stack-overflow fix, two panic fixes on malformed input, and a security policy clarification. Somebody is home.

The benchmark in the README is worth reading honestly. On a 200-document corpus, run by the authors on their own hardware on July 31, pdf-inspector scores 0.875 overall against liteparse at 0.873 and opendataloader at 0.831. It wins tables decisively, 0.814 against 0.693. It loses headings, 0.788 against 0.811. It is roughly a third faster than the next fastest thing. Read that as "in the same class as the good ones, and quicker," because two thousandths of a point on somebody's own bench is not a victory and treating it as one is how people end up disappointed.

There is a sibling repo that matters more than it looks. anydoc, also MIT, also from Firecrawl, first published on npm on August 4, turns fourteen document formats into the same Markdown: Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV, and PDF. It uses pdf-inspector underneath for the PDFs. It also runs as npx @firecrawl/anydoc statement.pdf with nothing installed first, which is the difference between a library and something an ops person can actually try on a Tuesday.

Why a routing decision is a line item

There have always been two ways to deal with a document pile. Buy a document automation product and pay per document forever, or build the thing yourself. The reason the second one almost never happened at a forty-person company is not that the AI was not good enough. It is that every version of the quote came back priced by the page, and per-page pricing on a pile that only grows is the kind of number that makes an owner close the tab.

Run it. A wholesale distributor takes in about 1,200 supplier documents a month: invoices, packing slips, freight bills, signed purchase orders, certificates of insurance. Call it two pages each. On Google's invoice parser at ten cents a document that is $120 a month, $1,440 a year, and it goes up every time the business does. On the form parser at thirty dollars per thousand pages, $72 a month. On plain OCR at a dollar fifty per thousand, under four dollars, but plain OCR hands you a wall of text and none of the structure you were paying for.

Now put the classifier in front of it. The invoices your suppliers email out of their own accounting systems are born digital. So are the e-signed POs, the bank statements pulled from a portal, most freight bills, and every PDF that was a spreadsheet twenty minutes ago. The text is already in the file, sitting there in plain view of anything that bothers to look. Those cost nothing and come back before you have finished blinking. What is left is the photographed delivery ticket, the faxed certificate, the packing slip somebody scanned at the counter with a phone. Those go to the meter, and only those. If your mix looks like the 54 percent, your document bill roughly halves.

Halving $1,440 saves you $720, and I am not going to stand here and tell you that changes a business. It does not. The number gets interesting at the other end of the range, where an insurance brokerage or a freight desk pushing 50,000 pages a month through a form parser is looking at $1,500 a month, $18,000 a year, and cutting that close to half is money somebody has to defend in a budget meeting. It also gets interesting in the other direction entirely, because the second thing being displaced here is not a bill at all. It is the ticket.

Somebody has to write the logic that asks "is this one scanned or not." That is not a hard problem, it is a fiddly one, it involves font tables and image coverage heuristics, and it is exactly the kind of two-week detour that turns a Friday afternoon build into a project you file a request for and never hear about again. That work is now a function call that returns in twenty milliseconds. For the ops person who wants to point an agent at the shared inbox and have supplier invoices land in the accounting system by themselves, the router was the boring blocker in the middle. It is gone.

And there is a quieter one. The 54 percent never leaves the building. If you handle medical records, employment paperwork, client financials, or anything where "which cloud did that document go to" is a question somebody will eventually ask you in writing, then the half of your pile that gets read locally is a half you no longer have to answer for.

The honest take

This is a library, not a product, and the word "free" is carrying a lot in everything above.

Start with what you would actually do. There is no interface, no upload box, no review queue, no dashboard, and no hosted version of pdf-inspector in the repo. The realistic path for a non-engineer is npx @firecrawl/anydoc against a folder, and then an afternoon with a coding agent wiring the classifier to your inbox and your accounting system. If you have shipped something with an agent before, call it three to six hours to a working prototype and another few to make it survive a real week. If you have not, call it a day, and do it on a folder of copies rather than the live pile. The Python path is worse than it looks, by the way: it wants maturin and a build step rather than a plain install. Node is the smooth one.

Hosting costs essentially nothing. This runs on the machine already on the desk, or on a six to twelve dollar server if you want it running when the laptop is closed. Your only bill is the OCR on whatever is left over, plus the model call that turns Markdown into fields.

Which is the real gap, so let me put it plainly. Google's invoice parser hands you typed fields: vendor, invoice number, line items, totals, each with a confidence score, ready to write into a system. pdf-inspector hands you Markdown. Between those two sits a schema, a model call, a validation step, a queue where a human looks at the ones the model was unsure about, and the integration that actually posts the record. That is the majority of the work in a document pipeline and none of it is in this repo. Anyone telling you a Rust library replaces an invoice processing product has not built an invoice processing pipeline.

The 54 percent is also not your number. It is a claim about PDFs at large, published by the company that wrote the tool, and your document mix is not the internet's. If you run a trades business, most of what arrives is a photograph of a piece of paper taken in a truck, and your figure might be fifteen percent. Run detect-pdf over a month of your own files before you believe any of the arithmetic above, including mine. It takes half a second per two hundred documents. There is no excuse for guessing.

On who maintains it: Firecrawl is a funded company, and this is the engine underneath a document parsing service they sell. That cuts both ways and you should hold both halves. It means the thing is maintained by people whose revenue depends on it being fast and correct, which is a far better guarantee than a weekend project. It also means the roadmap serves their product, not your pipeline, and if the company pivots or gets bought, the MIT license means you keep what you have and inherit the maintenance. Nine hundred and sixty-two forks is a decent lifeboat, not a promise.

Last thing, and it is the one people skip. You are pointing a parser at files that strangers email you. Yesterday's commit log includes a fix for a denial of service triggered by a self-referencing form structure inside a PDF, and a crash on non-ASCII input. Both fixed within a day of being reported, which is exactly what you want to see. It is also a standing reminder that a malformed document is an input to your system, and inputs from outside get run somewhere they cannot take the rest of your week down with them. A container, a separate box, a timeout. Not the machine your accounting system lives on.

None of that undoes the point. It sharpens it. The reason document automation stayed a purchase instead of a build was never that reading a page is hard. It is that somebody put a meter on the reading, and the meter ran the same whether the page needed reading or not.

The file already knows what it says. Everything you were about to pay for was the assumption that it did not.