Convert PDF Form to Excel: Fields, Not Tables

To convert a PDF form to Excel, read the values stored in its fillable fields rather than the printed page. Each field has a name and a value, so the field names become your columns and each filled form becomes one row. Free tools can export those fields. Table converters, including bank statement tools, read the wrong layer.

What makes a PDF form different from a PDF table?

A PDF form stores its answers as named fields that sit on top of the page, while a PDF table is printed text laid out in rows and columns. A table converter looks for text that lines up. A form's answers are separate objects, each named, such as "applicant_phone", and they rarely line up.

Think of a fillable form as two layers. The bottom layer is the printed page: labels, boxes, instructions and a logo. The top layer holds the fields people type into, each one tied to a spot on the page. When you open the file in a viewer, you see both layers merged, so it looks like one page. Underneath, the answers live in their own structure inside the file.

That difference decides which tools work:

• A table tool scans the page for rows. On a form it finds labels scattered across the page, a few answers mixed in, and no clear columns. The output is a jumble of cells.
• A field reader ignores the page layout and asks the file for its list of fields. It gets back clean name and value pairs, which map straight onto spreadsheet columns.

A bank statement is the opposite case. Its transactions are printed text in a repeating row pattern, with a date, a description, an amount and a balance on each line. That is exactly what table readers are built for, and it is why a statement converter does well on a statement and badly on a form.

Checking a PDF form for fillable fields

A PDF form is fillable if you can click into a box and type, and it is flattened or scanned if you cannot. This check takes under a minute and decides your whole route, because only a fillable form still carries named fields that a free tool can export.

Run these three checks in order on one copy of the form:

1. Click a box. Open the file in a PDF viewer and click where an answer goes. A blinking cursor or a highlighted box means the field is live.
2. Try to select the answer text. If a filled answer cannot be clicked as a field but can be selected as text, the form was flattened: the answers were printed into the page and the fields removed.
3. Try to select anything. If nothing on the page can be selected, the file is an image, usually a scan or a photo of a paper form.

Write down the result for each batch of forms. A folder of returned forms often mixes all three, because some people fill the file on screen while others print it, fill it by hand and scan it back. Sort the files into three piles before you choose a tool, since each pile needs a different method.

Free ways to extract data from a PDF form to Excel

The free ways to extract data from a PDF form to Excel are a short script that reads the fields, the form-data export in a full PDF editor if you already own one, and typing by hand for a handful of forms. A script suits a big pile. Typing suits five forms or fewer.

Read the fields with a script

The free Python library pypdf can list a form's fields and their values. Its documentation on reading PDF form fields with pypdf shows get_form_text_fields(), which returns a mapping of text field names to their values, and get_fields(), which returns every field, including check boxes and choice lists. The script below reads text fields only; switch to get_fields() and read each value if your form relies on check boxes. A loop over a folder of files can write one line per form to a CSV file that Excel opens directly.

import csv, glob
from pypdf import PdfReader

rows = []
for path in sorted(glob.glob("forms/*.pdf")):
    fields = PdfReader(path).get_form_text_fields()
    fields["source_file"] = path
    rows.append(fields)

columns = sorted({key for row in rows for key in row})
with open("forms.csv", "w", newline="") as f:
    writer = csv.DictWriter(f, fieldnames=columns)
    writer.writeheader()
    writer.writerows(rows)

The same documentation lists caveats worth knowing. A radio button group comes back as its parent group, not each button. The shape of a value depends on the field type, so not every value is plain text. A field missing from the form's field list will not appear at all.

Use the export in a PDF editor you already have

Full PDF editors usually include a way to export form data, and some can gather several returned forms into one data file. If your office already pays for such an editor, look in its help pages for "form data" and test the export on two forms. Buying an editor only for this job is rarely the cheap route when a free script does the same work.

Type the answers

For a few forms with a few fields each, typing is quick and needs no setup. Put field names across row 1 and one form per row below. Past roughly a dozen forms, the script pays back the time it takes to set up.

Worked example: twenty filled PDF forms in one Excel sheet

A finished sheet from twenty filled PDF forms has one column per field name and one row per form, plus a column naming the source file. The example below shows the first three rows of such a sheet. The names, values and file names are made up for illustration.

Three habits keep a sheet like this trustworthy:

• Keep the source file column. When a value looks wrong, you can open the exact PDF it came from.
• Count the rows. Twenty forms in the folder should give twenty data rows. A missing row usually means one file was flattened or scanned and returned no fields.
• Look for empty cells. The empty start date in row 3 is a real gap in the form, not an export error. Flag it for follow-up rather than guessing.

Field names come from whoever built the form, so they can be cryptic, such as "Text7" or "Check Box3". Rename the header row in Excel once, and keep a note of which original name maps to which column, so the next batch lines up.

The same row-per-document idea applies to paperwork that is not a form. A payslip, for instance, is a printed table with current and year-to-date columns, and getting payslips into Excel by download, typing or conversion compares the routes for a year of them.

Does Excel's PDF import read PDF form fields?

Excel's PDF import does not read form fields. It looks for tables printed on the page. Microsoft's documentation for the Power Query PDF connector says its entry point "returns any tables found in a PDF file", with options for page ranges and tables that run across pages.

That is useful for a statement or an invoice with a clear grid, and it is the wrong tool for a form. On a fillable form, Get Data from PDF may find the printed labels and boxes, and it may show some typed answers if they happen to sit in a grid. It does not ask for the field list, so it can miss answers, merge labels with values, or skip check boxes entirely.

There is one case where it helps. A form that was flattened, so its answers are now printed text, sometimes has a tidy layout that Power Query reads as a small table. Test it on one file. If the Navigator shows a table with the answers in a column you can pick out, you can load one form at a time. The same Microsoft page notes that a Folder connector can import several PDF files at once, which can save repetition if the layout holds across the batch.

When a bank statement converter is the wrong fit for a PDF form

A bank statement converter is the wrong fit for a PDF form because it looks for transaction rows, not named fields. CheapBankConvert, for example, returns a date, a description, an amount and a balance for each line of a statement. A form has none of those, so paying to convert one buys the wrong output.

The mismatch shows up in practice:

• A form's answers are scattered across the page, so a row reader finds no repeating pattern.
• Check boxes and drop-down choices are field states, not printed text, and a row reader cannot see them.
• Even where text is found, the result has no field names, so you would rebuild every column by hand.

The free routes above fit a form better, and none of them costs money. Keep paid conversion for the documents it is built for. If your stack is really bank statements, the price arithmetic for a long run of months is in converting two years of bank statements without overpaying, and the twelve-month version, with the bundle math, is in converting a year of bank statements for less. CheapBankConvert's homepage has the early per-statement prices and a price check for those cases.

Flattened and scanned PDF form edge cases

A flattened PDF form has lost its fields, and a scanned one never had them, so a field reader returns nothing for either. A flattened form still holds selectable text that a copy and paste or a table reader can sometimes recover. A scanned form needs optical character recognition, which reads the image and guesses each character.

For a flattened form, try these in order:

1. Ask for the original. The person who sent it may still have the fillable version, which gives clean fields in seconds.
2. Copy the answers. Select the text of one answer, paste it into Excel, and repeat. Slow, but exact for a few forms.
3. Try a table read. If the layout is regular, Power Query may read it as a small table, as described above.

For a scanned form, the answers were often handwritten, and handwriting is where character recognition struggles most. Typed answers on a clean scan recognize far better. If your office copier has a scan-to-Excel or OCR option, the copier scan to Excel guide covers the settings and what the opened file looks like. For handwritten forms, plan on typing and use the scan only as the source you read from.

One rule holds for every pile: check a few results against the original form before you rely on the sheet. A field export can still return an answer in the wrong format, such as a date typed as "Sept 1", and a scan can turn a 7 into a 1. Five minutes of spot checks saves an awkward correction later.