PDF Form to Excel

Pull the answers out of filled PDF forms and into one spreadsheet

You made a PDF form. People filled it in, which was the whole point, and now you have a folder of PDFs and a problem: the data lives in twenty files instead of one table. Retyping it is slow and you'll make mistakes somewhere around form eleven. This tool reads the form fields directly and hands you an Excel file where every PDF is one row, every field is one column, and the first column tells you which file each row came from.

Upload one form or a batch of up to twenty. Either way you get a single .xlsx back, named after your first file, ready to sort and filter like any other spreadsheet.

What counts as a PDF form here

The tool reads fillable PDF forms, the kind formally called AcroForms. If you can open the PDF in a browser or Adobe Reader, click into a box, and type, that's the kind. Text fields, checkboxes, radio buttons, dropdown lists, and multi-line comment boxes all come out. This covers most application forms, intake sheets, registration forms, and order forms made in Acrobat, LibreOffice, or Word's PDF export.

What it can't read is a scanned paper form. That's just a picture of a form, with no live fields inside it, only a photo of ink on paper. If what you actually have is a regular PDF with tables in it, that's also a different job, because tables aren't form fields either.

For table-style PDFs, our PDF to Excel converter pulls the table data instead.

For scanned forms, run it through our OCR PDF tool to get the text out. That's a different kind of reading, but it's the one that fits paper.

How the extraction works

The work happens on the server, not in your browser. Your files join a queue, and a Python routine built on PyMuPDF walks through each PDF page by page, reading every form widget it finds. Field names become the column headers, in the order they first appear in your documents. Values get cleaned up on the way out: a ticked checkbox becomes Yes and an unticked one becomes No, a radio button group reports whichever option was selected, and a dropdown shows the chosen entry rather than some internal code.

Batches don't have to be identical. If you upload two slightly different versions of a form, the spreadsheet grows a column for every field that exists anywhere in the batch, and forms that don't have a particular field simply leave that cell blank. That sounds like a small thing until you're merging last year's application form with this year's, and it saves the whole exercise.

One bad file won't sink the batch

Real batches are messy. Somebody sends back a password-protected copy, somebody else prints the form, signs it, scans it, and returns a flat image. Instead of failing the whole job over one awkward file, the spreadsheet gets a Notes column: the readable forms fill their rows normally, and the problem files get a row that says what went wrong, whether that's a password or a missing set of fields. You can chase those two people later without losing the other eighteen answers.

If none of the uploaded files contain form fields at all, you get a clear message saying so rather than an empty spreadsheet, along with a pointer to the tool that actually fits.

Small details the spreadsheet gets right

• The header row is bold and frozen, so field names stay visible while you scroll through rows.
• Column widths are sized to the content instead of everything arriving squeezed to eight characters.
• The file name sits in the first column, so you can always trace a row back to its PDF.
• Anything a person typed that starts with an equals sign is stored as plain text, not as a live formula. A malicious form entry shouldn't get to run calculations in your spreadsheet, so it can't.

Honest limitations

A few things to know before you rely on this. Old LiveCycle forms, the XFA kind some government agencies still use, aren't supported; they're a different technology that even Adobe has moved away from. Password-protected files won't be forced open either; it stops at the lock and says so.

The fix takes a minute: unlock the PDF first, then run the unlocked copy through again.

Column headers are whatever the form's author named the fields. A well-built form gives you clean headers like full_name and email. A lazily built one gives you Text1 through Text14, and there's nothing any extractor can do about that except hand you the names as they are. The values will still be right, and renaming a header row in Excel takes seconds.

And if your problem is the reverse, you have a filled form that should stop being editable before you send it on, flatten the PDF to lock the answers in place.

A real example

Say you're renting out a flat and fourteen people returned your application form. Upload all fourteen PDFs, wait a few seconds, and download one sheet with a row per applicant: names, phone numbers, move-in dates, and whether they ticked the box about pets. Sort by move-in date, delete the rows you're not calling back, and you're done before you'd have finished retyping the second form. The same shape of problem shows up everywhere: clinic intake forms, event registrations, expense claims, permission slips, supplier questionnaires.

Limits and file handling

Up to 20 PDFs per batch and 100 MB combined, with the per-file limit shown on the upload zone. Got more than twenty forms? Run them in batches and paste the rows together in Excel; the columns will line up as long as the forms match. Processing is quick because form fields are tiny compared to the pages they sit on. Even a large batch usually finishes in seconds.

On privacy: uploads travel over an encrypted connection, live on the server only while the job runs, and are deleted the moment it finishes. The Excel file you download is the only copy that matters. Nothing is kept, read, or passed to anyone else.