PDF Data Extractor

The problem

Pulling specific fields out of a large batch of PDFs is a job that usually ends in one of two bad places: hours of manual copying, or uploading confidential documents to a cloud service. For anything covered by a confidentiality obligation — legal, medical, financial — the second option is not available at any price, which is why the manual version persists.

How it was built

Built as a local desktop application rather than a web tool, which is the whole point: documents never leave the machine, so there is no vendor to trust, no data-residency question, and no upload step. Privacy here is an architectural property, not a setting.

Extraction is search-driven with context capture — rather than requiring a fixed template per document type, the tool locates target terms and pulls the surrounding context, which is what makes it work across a batch of PDFs that are similar but not identical.

Results export to Excel, because the output of a data-extraction job is almost always an input to something else, and that something else is a spreadsheet far more often than an API.

Batch processing is the design center. Extracting from one PDF is a solved problem; doing it across a large directory without babysitting it is where the time is actually saved.

Why this stack

• Local desktop application — the deployment target is itself the privacy guarantee.
• Excel export — meets the user where their workflow already is.

Outcome

• Processes large batches of PDFs while keeping all data on the local machine.
• Source available on GitHub.

Frequently asked questions

Why a desktop app instead of a web tool?

Because the documents it is designed for often cannot legally or contractually be uploaded to a third party. Running locally removes the question entirely rather than answering it with a privacy policy.