Why I built Pdf2Fill

Whenever I would need to fill a PDF, I would spend time manually adding textboxes (sedja.com, ilovepdf.com etc), moving them around, making sure the positioning and font size looks good because I don’t own Acrobat. So I built Pdf2Fill, it finds the fields, allows you to type and download. Doesn't require you to create an account and free to use.

How it works

The interesting problem is field detection on flat PDFs, the ones never built as interactive forms. A government PDF is often just text and lines drawn on a page, with no field objects in the file at all.

So the engine reads the page geometry: underscore runs and drawn rules for blank lines, small squares and their nesting for checkboxes, comb cells for character-by-character boxes, and glyph-drawn checkboxes where the box is a font character rather than a shape. That last one broke my contour detector for weeks, because a checkbox rendered as a Wingdings glyph has no path to find.

It's a Python backend built on a package I wrote called pdfields. The frontend renders overlays on top of the page image.

I tested against a corpus of 23 real documents: W-9, W-4, Canada's TD1, New Zealand's IR330, the HMRC starter checklist, bank direct-deposit forms, medical intake forms, a US court form, a French cerfa, lease and contractor agreements. Every field is annotated by hand. That corpus is the only reason I trust any change I make, and it's caught several "improvements" that were actually regressions.

The tradeoff I made

Filling happens on the server, not in your browser. I chose that because the Python PDF libraries are much better than what I could run client-side, and detection quality was the whole point of building this.

That means your file gets uploaded. Being precise about what happens to it: it's never saved to an account, a database, or a document library, and it's automatically deleted from the server within an hour of your last activity. There's no permanent copy, and connections are HTTPS.

If you're filling something sensitive and would rather nothing left your machine at all, that's a fair objection, and this tool doesn't meet it today.

What it doesn't do (yet)

Image-only scans. There's no OCR yet, so a photographed or scanned form gives the detector nothing to read. It's the most requested feature and it's what I'm looking at next.

My dilemma

Monetization. It's free, there's no account, and there's no watermark, which are the three things people say they want and also the three things that make it hard to charge for. I'd rather not add an account requirement, since avoiding that is why I built it.

What I’m looking for from the IH community:

• Where does field detection fail?

• UX feedback – is the flow intuitive?

• Would you pay filling more than 3-5 PDFs a month?

Check it out at https://pdf2fill.com/.

Edit: tightened the description of how files are handled. Filling runs server-side, the host keeps standard access logs, and files auto-delete within an hour. The original wording said "no logs, no storage," so I updated this post to make it more accurate.

Edit #2: I added a blogpost showing how we measured the detection reliability. The write-up includes the two fixes we tried that failed measurement and an answer-key defect we found in our own data.https://pdf2fill.com/blog/pdf-field-detection-real-forms.html.
Happy to paste specific numbers here if anyone wants them.