PDF form field inspector — what an AcroForm dictionary contains and how to read it
PDF forms look like simple fill-in-the-blank documents, but underneath every fillable PDF is a structured AcroForm dictionary that lists every interactive field, its type, its constraints, and its current value. Most PDF readers hide this structure; you click into a field and type. But for compliance audits, data extraction pipelines, form-quality reviews, and accessibility checks, getting the structured field list out is exactly what you need. Here is what each AcroForm field type means, the five real workflows where surfacing the structure pays off, and the difference between this inspector and the Fill PDF Form tool.
What's in an AcroForm dictionary
Every fillable PDF has an /AcroForm entry in its catalog that points to a /Fields array. Each entry in that array is a field dictionary — a structured record with a name (/T), a field type (/FT), an optional default value (/DV), an optional current value (/V), and a set of flags (/Ff) that control behavior (required, read-only, no-export, multiline, password, etc.). Fields can have child fields, creating a tree structure that mirrors the form's logical sections.
Reading the AcroForm tree gives you the form's complete data model: what data the form collects, the types of each field, the validation constraints, and any pre-filled defaults. The inspector walks that tree and surfaces every leaf field with its full set of properties.
Four field types and what each means
The PDF spec defines exactly four AcroForm field types — every fillable field is one of these:
- Tx — text input. Single-line or multi-line text fields. Multi-line is signaled by a flag (/Ff bit 13). Password fields are also Tx with a password flag — same type, different display.
- Btn — button. Includes checkboxes (toggle on/off), radio buttons (mutually exclusive group), and pushbuttons (execute a JS action when clicked). Flags distinguish the subtypes.
- Ch — choice. Dropdowns and listboxes. The list of options is stored in /Opt. Editable combo-boxes (where users can type a value not in the list) are signaled by a flag.
- Sig — signature. Placeholder for a cryptographic signature. When signed, the field's /V holds the signature dictionary with certificate, timestamp, and signed-bytes hash.
Flags worth knowing
The /Ff (field-flags) bitmask carries behavioral metadata. The most-asked flags:
- Required. Form-submission processors should reject the form if the field is empty. The inspector surfaces required fields explicitly so you can see which inputs the form considers essential.
- Read-only. Field cannot be edited via PDF readers. Often used for computed fields that derive from other fields, or for pre-filled fields that should not be changed by the recipient.
- No-export. Field is filled but its value is excluded from form-data exports. Used for fields that are visual-only (e.g. computed totals that should appear on the rendered PDF but not in extracted data).
- Multiline (Tx only). Text field accepts line breaks. Without this flag, even if the field is visually large, the input is a single line that scrolls.
- Password (Tx only). Display masks the typed characters with bullets. Note: this is display-only — the underlying value is still stored in clear text in the PDF.
Five workflows where the inspector pays off
Cases where you need the field list as data, not as an interactive form:
- Form-data extraction pipelines. Reading filled forms and ingesting the values into a database. The inspector lists field names + types + current values as CSV/JSON, which the pipeline consumes directly. Faster and more reliable than OCR on the rendered form.
- Compliance audits. "What data does this intake form collect?" The inspector surfaces every field, which compliance can review against PII / data-minimization policies.
- Form quality reviews. Are required-field flags set correctly? Are read-only flags blocking accidental changes? The inspector makes form structure visible for review without filling it.
- Accessibility audits. Each field's tooltip (/TU) and tab order should be set for screen-reader access. The inspector surfaces both so accessibility reviewers can verify them.
- Multi-form data mapping. When mapping fields from form A to form B (e.g. for a workflow that auto-fills application B from application A), the inspector's exported field list is the input to the mapping spec.
Inspector vs Fill PDF Form — when to use each
Two related tools, different goals:
- Inspector — surface the structure. Read-only. Output is the field-list as JSON / CSV. Use when you need to see what the form looks like in data form, not when you need to add values to it.
- Fill PDF Form — add values. Modifies the PDF. Each field gets a value you type. Output is the filled PDF. Use when you actually want to complete the form.
Limits and compatibility
On the free web tool, the form-field inspector handles PDFs up to 100 MB. Parsing runs in your browser via byte-level parsing; nothing is uploaded. Output is a structured list of every AcroForm field with name, type, value, defaults, and flags. Exportable as JSON or CSV.
Common pairings: Inspector → Fill PDF Form when you want to fill the surveyed form. Inspector → AI · Fill when the source PDF is flat (no AcroForm) and the inspector shows zero fields — that's the trigger to use the visual-detection AI variant.