Extract Form Fields
Reads a PDF's field inventory — names, types, page numbers, character limits and allowed choices — before anything can be written into it.
Overview
You cannot fill what you cannot see. Before any value is written into a form, something has to establish what the form actually contains: how many fields there are, what type each one is, which page it sits on, what it will accept. That inventory is what this step produces, and it is the first thing that happens to a form on its way in.
It is not only a machine step. Anyone who has been handed a 14-page state application knows the first question is "what does this thing actually ask for?" — and the answer is usually buried across pages of small print. A field inventory answers it directly: 214 fields, three dropdowns limited to specific option lists, the character limit on each box that declares one.
The inventory also settles the question that decides the rest of the run. A form that reports fields has an interactive layer to write into, and goes on to be processed as a fillable form. A form that reports none goes onto the conversion path instead, because there is nothing to write into yet.
What It Does
| Capability | What it means for you |
|---|---|
| Field names | A text or choice field comes back under the name the document gives it, which is the name filling refers to |
| Field types | Each field's type is reported exactly as the document declares it, so a checkbox is never taken for a text box |
| Page and position | Which page each field is on and where on that page it sits, which is what makes page-by-page review and coordinate-based work possible |
| Character limits | A field that declares a maximum length is reported with it, before a too-long value becomes a problem |
| Allowed choices | Dropdowns and list boxes come back with the values the form will accept, so a value is picked from that set rather than guessed |
| Radio options individually | Each option of a radio group is its own entry, named for the option it selects |
| Checkboxes with a custom on-value | A checkbox whose on-state is a value of its own rather than a standard one comes back with that value added to the document's name |
| Labels where the form has them | A field carrying a human-readable label is reported under that label as well as its raw name — which is what makes "Text12" usable |
When This Runs
Nothing selects this. Reading a form's fields is part of taking the form in: it happens before anything can be filled, and neither you nor the agent decides to invoke it.
- A form is taken in. This is the first step, and it gates everything after it: what comes back decides whether the form is processed as fillable or put on the conversion path first.
- A form's document is replaced. Replacing it re-reads the fields and recomputes the form's field fingerprint, so a field map from the previous edition is not carried forward onto a re-laid-out revision.
- A form is filled. The inventory is compared against the values being written, and every field that is not being written to is explicitly cleared rather than left holding whatever was in it.
A document can also be inspected on its own just to answer whether it has any fields at all — the question that separates a form that can be filled natively from one that has to be converted first.
Inputs and Outputs
Takes: a PDF.
Returns: a flat list of fields in page order, each carrying its own page number. It is not a per-page structure: a page with no fields on it contributes nothing, so there is no entry anywhere saying that a particular page is empty.
Where the form already holds values, those come back with the fields, which is what makes reviewing a part-completed form possible.
Example
A contractor uploads a six-page municipal permit application nobody in the workflow has seen before.
The inventory comes back with 168 fields. Most belong to the first four pages — applicant details, property information, scope description, a contractor licence block — and the fee schedule accounts for 22 more. The instruction sheet contributes nothing, so no field in the list points at it.
The detail that saves a rejected submission: the licence number field declares a limit of 12 characters, and this contractor's licence, written the way the office writes it, is 15. The limit is visible now, during setup, rather than three minutes before a filing deadline. Nothing checks the value against the limit, so it takes somebody looking — but the number is there to be looked at.
Limits
- It reports what the PDF declares, not what the form means. A field named "Text12" comes back as "Text12". Understanding that it is the co-borrower's middle name comes from the form's layout and context, not from the inventory alone.
- Badly authored forms produce messy inventories. Duplicate names and leftover fields from an earlier revision are common in real agency PDFs, and they are reported as faithfully as the good ones.
- Nothing found and nothing readable look identical. A document that cannot be opened or read comes back as an empty inventory — the same result a genuinely flat document gives. An unexpected zero is worth opening the file over.
- Only text, checkbox and radio fields make a form fillable. A PDF whose only interactive fields are dropdowns, list boxes or signature boxes is handled as though it had none at all.
- Dynamic XFA forms are recorded as unsupported. A PDF built on that dynamic layout format is marked unsupported with an explicit reason rather than partially read.
- Option lists come back unordered. The values a dropdown will accept are all there, but not necessarily in the order the form lists them, and an option that appears twice appears once.
- Flat documents have nothing to report. A scanned form is an image; there is no field structure to read. That is a conversion problem, not an extraction problem.
- It does not validate the values. Knowing a field holds 12 characters says nothing about whether the value put there is correct.
FAQ
How do I find out what fields a PDF form contains?
Run a field extraction against it. You get every field's name, type and page, along with character limits and the values dropdowns will accept. For a long agency form that is usually faster than reading the form itself, and it surfaces the duplicated and leftover fields a reader would never notice.
What does it mean if the extraction returns no fields?
Usually that the PDF is flat — a scan, a photo, or an export with no interactive layer — and a flat form gets put on the conversion path automatically, because nothing can be written into fields that do not exist. The same empty result also comes back from a document that could not be read at all, so a zero on a PDF you know to be fillable is worth investigating rather than accepting.
Why are the field names in my PDF meaningless?
Because most form authors never expected anyone to read them. Names like "Text12" and "Check3b" are what PDF authoring tools generate by default. They are reported faithfully, and where the form's author bothered to attach a human-readable label to a field, that label comes back alongside the raw name.
Does it tell me the maximum length of each field?
Where the form declares one, yes. That is worth knowing up front — a licence number or policy reference that is three characters too long for its box is the kind of problem best discovered during setup rather than at submission.
Can it read the values already filled into a form?
Yes, as long as the form still has live fields. Existing values come back alongside the field structure, which is what allows a partially completed form to be reviewed or topped up.
Does this work on a form I scanned from paper?
Not for finding fields, because a scan has none. A scanned form needs converting into a fillable version first, after which extraction reports the fields that conversion created.