Almost every organisation has a document that arrives the same way every week and is never quite the same shape twice. Invoices from forty suppliers. Remittance advices. Bank statements. Delivery notes. Lead records generated on demand by a system nobody has permission to change.
They are the same kind of document. They are not the same layout. And that distinction is why extracting data from them is harder than it looks.
The three options, and what's wrong with each
Re-type it. This is what most people actually do, and it is not stupid. It works on the first document and it works on the four hundredth. It is just slow, and it introduces exactly the kind of error nobody catches — a transposed pair of digits in a total, six weeks before anyone reconciles it.
Send it somewhere. There are good tools that will read a PDF if you upload it. For a great many people that option simply is not available. If the document contains a customer's name and address, a patient reference, a supplier's pricing, or anything covered by a confidentiality clause, then "upload it to a service and see what comes back" is not a decision one person gets to make on everyone else's behalf. Plenty of teams discover this only after they have built a process around it.
Write a parser. If you have engineering time, you can extract by coordinates or by regular expression. This works beautifully until the layout shifts. Then it does not fail — it returns the wrong value confidently, and it keeps doing so until somebody notices. Parsers written for documents you do not control are liabilities with a delay fuse.
What is actually missing
All three failures come from the same gap. Nobody can describe where a value is in a way that survives the page moving.
A coordinate says "the total is at x=412, y=88". That is true of one document. An expression says "find the number after this pattern". That is true until the pattern appears twice. What you want to say is closer to: the total is the number to the right of the words "Amount due", wherever those words end up.
That is the sentence PDFGrid lets you write, except you write it by pointing at the document rather than by typing.
What that looks like in practice
You open a PDF and define a rule. You can draw a region and take what falls inside it. You can anchor to a phrase and take the value that follows it, so the rule tracks the phrase down the page. You can use position relative to the page, or a pattern where a pattern genuinely is the right tool. You choose whether you're capturing a word, a number or a date, and the engine reads it as such.
The rule resolves on the document in front of you. Then you apply it across the rest of your documents, and every extracted value is shown to you in a grid before anything leaves for a spreadsheet.
For a practical walkthrough, see how to extract data from multiple PDFs to Excel.
That review step is not decoration. PDFGrid is a rule engine, not a judgement engine: it returns exactly what your rule says to return, and if the rule is pointed at the wrong place it will return the wrong thing confidently. The grid exists so that you find out then, and not in a month.
Why it runs in your browser
The PDF engine is compiled to WebAssembly and runs on your own machine. Your documents are not uploaded, because there is no upload endpoint to send them to. That is not a policy I could quietly change; it is a property of how the thing is built.
You do not have to believe me. While you are online, load the workspace and leave it open briefly so its local PDF components can prepare. Then disconnect, open your PDFs, and run an extraction. The documents, extraction, and results preview run on your device, so you can keep working without an active connection once those components are ready.
One limitation: the spreadsheet-export module may only be requested after an extraction, or when you select "Download Excel". If it has not already loaded before you disconnect, downloading an Excel file needs a connection. You can still use "View Offline" to inspect and copy the CSV results on your device.
Where it is now
I built this because I needed it. In a previous role I was working through fifty to a hundred client records a week, all arriving as dynamically generated PDFs containing other people's names and addresses. My best available answer was several weeks of building a Power Automate Desktop flow that depended on every file having the right name in the right folder, and which returned wrong values silently when a document came out differently. I wanted something better and could not find it.
PDFGrid is early. It is free while it is in early access, there will always be a free tier, and it is built and run by one person in the UK. If you try it and something breaks, or a rule cannot express what you need, I would like to know — support@pdfgrid.app.