You have probably met both kinds of PDF form. In one, you click a box and type, tick a checkbox, pick from a dropdown, and the text sits neatly in place. In the other, clicking does nothing: the "form" is just a picture of a form, printed lines and empty boxes that you cannot type into at all. The difference is invisible in a thumbnail and often invisible in a quick visual check, because both look like forms. The real difference is structural: a fillable PDF contains form field objects, each with a name, a type, and properties. A flat PDF contains none.
The PDF Form Field Inspector lists those field objects. You provide a PDF, and it reports every field: its name, its type, its page, whether it is required, whether it is read-only, and its current value, if any. The inspection runs in your browser, so a form containing personal or sensitive information stays on your device.
How the tool works
A fillable PDF form is built on the AcroForm structure: a dictionary of fields, each with a type. Text fields accept typed input, sometimes with formatting rules such as a date or number format, a maximum length, or multiline input. Checkboxes and radio buttons accept a choice, with radio buttons grouped so that only one option in a group can be selected. Dropdowns (choice fields) offer a list of options, sometimes allowing a custom entry as well. Buttons trigger actions, such as submitting the form or resetting it. Signature fields hold digital signatures. Each field also has properties: a name that identifies it in the data, a default value, a required flag, a read-only flag, and sometimes a tooltip or formatting script.
The inspector reads that structure and presents it as a list, usually grouped by page or in field order. The field names matter more than they first appear: when a filled form is submitted, the data is sent as name-value pairs, so a field with a vague or duplicated name produces vague or colliding data. A field named "Text1" tells the receiving system nothing, while a field named "applicant_email" tells it exactly what it holds. The required flags matter too: a form that marks nothing required will accept a blank submission, and a form that marks everything required will reject a legitimate partial save, depending on how the receiving system treats the flags.
The inspector also reveals absence, which is itself a diagnosis. A PDF with no fields at all is not a broken form; it is not a form. It may be a scanned paper form, a flattened form whose fields were deliberately removed after filling, or a document that was only ever meant to be printed. Each of those has a different remedy, and the inspector's empty list is what tells you which situation you are in.
A worked example
Suppose you inspect an application form and the inspector lists eight fields: five text fields, two checkboxes, and one dropdown. Add them up — 5 + 2 + 1 = 8 — and you have the complete inventory. Three of the fields are marked required: full name, email address, and signature date. The remaining five are optional. One text field, the phone number, has a maximum length of 15 characters, which is worth noting: an international number longer than 15 characters will be truncated, not rejected, and the applicant may never notice.
Now test the form against that inventory. Open the PDF and try to type into each listed field. If a listed field cannot be typed into, check its properties: it may be marked read-only, which is sometimes deliberate — a field pre-filled by the sender that the applicant should not change — and sometimes an error, where a field that should be editable was locked by mistake. If a visible box on the page has no corresponding field in the list, that box is drawn decoration, not a field, and applicants cannot type into it no matter what they try. That mismatch between visible boxes and real fields is one of the most common form defects, and it is invisible without inspection: the form looks complete, but one of its boxes is a picture of a box.
A second useful check is the field names. Suppose the five text fields are named "Text1" through "Text5". The form works for typing, but the submitted data arrives as five meaningless labels, and whoever processes the applications must guess which value is the name and which is the email. Renaming the fields in the source — before the form is distributed — turns the submitted data from a puzzle into a usable record. Field names are metadata, and metadata is where a form's usability for the recipient is decided.
Common mistakes
The most common mistake is distributing a form without inspecting it. The form was designed in one tool, exported from another, and emailed to applicants, and nobody checked that the fields survived the export. Some export paths flatten forms silently, turning a fillable form into a picture of one. Inspection takes a minute and catches that failure before applicants do.
The second mistake is assuming a scanned form can be filled digitally. A scan is an image, and images have no fields. The remedy is not a different viewer; it is recreating the form as a real form, or running the scan through a process that adds fields — which still requires a human to place and name them correctly. Telling applicants to "just type into it" when the file has no fields wastes everyone's time.
The third mistake is flattening a form at the wrong moment. Flattening — converting fields into static text — is the right final step when a filled form must be preserved exactly as submitted, because it prevents later edits. But flattening a blank form destroys it as a form: recipients receive a document they cannot fill in. Flatten only filled copies, and keep an unflattened blank master for distribution.
The fourth mistake is ignoring the required flags. A form whose required fields do not match the process that receives it causes two kinds of failure: submissions that arrive incomplete because nothing was marked required, and applicants blocked from submitting because a field is marked required that they legitimately cannot complete yet. Review the required list against the actual requirements of the process, not against a guess made during design.
Honest limitations
An inspector lists fields and properties; it does not test them. It cannot tell you whether a field's formatting script works, whether a dropdown's options are complete, or whether the submit button sends data to the right destination — those need a live test with a filled form. It also cannot judge whether field names are sensible, only what they are, and it cannot repair a form: adding a field where a drawn box sits requires a form editor, not an inspector. Some PDFs use a different form technology, such as XFA, which is less widely supported and may not be fully reported by an inspector built for AcroForm. In that case an empty or partial field list may mean the form uses XFA, not that it has no fields, and a different tool is needed to examine it.
Closing
List the fields, count them, check the types and required flags, and compare the list with the boxes you can see. A form whose visible boxes and real fields match is a form applicants can actually complete; a mismatch is a defect to fix in the source, before distribution. To fill and use PDF forms, try Fill PDF Forms, and to lock a filled form against later edits, use Flatten PDF Forms. For the flattening step itself, see How to Flatten PDF Forms Before Sharing Them.