The PDFGrid story

Hello, I'm Emil. I'm a project manager and a developer, which in practice means I notice when work is slower than it needs to be, and then find it very hard to leave alone.

I'm a believer in kaizen — improvement through small, steady changes rather than one big fix. Usually that means a five-minute rearrangement nobody else notices. Occasionally the small change turns out to be a tool.

This is one of those.

The job that started it

I was working through fifty to a hundred client leads a week. Because of how the systems were wired together, every one of them arrived as a PDF, generated on demand — one per lead.

They were never quite the same. The same field could sit in a different place on two documents produced an hour apart, because the layout flowed around whatever content happened to be there. There was no fixed template to rely on, which meant there was nothing for a simple rule to point at.

The obvious answer was one of the many web tools that will read a PDF for you. I never seriously considered it. Those documents held other people's full names and home addresses. Handing them to a service I knew nothing about, so that I could save myself an afternoon of typing, was not a decision I had any business making on their behalf.

So I built a workaround instead. Power Automate Desktop, several weeks of work, and a flow that did the job — as long as every file was named the way it expected and sat in exactly the right folder. The extraction rules were positional and brittle. When a document came out slightly different, the flow didn't fail loudly. It returned the wrong value and carried on.

That's the part that stayed with me. I had spent weeks building something more fragile than the problem it solved, and I still had to check every result by hand.

What I wanted instead

I looked for a tool that would do this properly and couldn't find one. The good ones I found wanted the documents on their servers. The ones I found that ran locally were either developer libraries — write a parser, then maintain it forever — or they assumed every document was identical. Nothing I found let me point at a value, say "that one, wherever it moves to", and see straight away whether I had got it right.

PDFGrid is that tool.

You open a PDF and define a rule — by drawing a region, or by anchoring to a phrase that sits near the value you want — and watch it resolve. Then you run it across the rest of your documents and check every result in a grid before anything is exported. The rules follow the value when the layout moves. That is the whole point of them.

It works that way because of the kaizen thing, really. One rule at a time, verified as you go, so you always know exactly where you stand — rather than one large automation you configure once and then have to trust. Small steps you can check beat big steps you can't.

And it runs entirely in your browser. Not encrypted in transit — there is no transit. There is no upload endpoint to send a document to, which is a property of how the thing is built rather than a promise I am asking you to take on faith. Open your network panel and run an extraction; there is nothing to see.

PDFGrid is early. It is free while it is in early access, and there will always be a free tier. I build and run it on my own, from the UK. If you find something wrong with it, I would genuinely rather hear about it than not — support@pdfgrid.app.