PDF Form Field Types Explained

When you open a fillable PDF and click in a box, you are interacting with a form field. Behind that simple interaction sits a small zoo of field types, each with different behavior, different properties, and different best-fit use cases. Knowing them is the difference between forms that just work and forms that frustrate everyone who fills them. This guide walks through the field types in the PDF specification, how to choose between them, and the gotchas that trip up form designers.

The two form models in PDF

A PDF can use either of two form technologies:

AcroForm. The original PDF form model. Static layout, fields placed at fixed coordinates, broad reader support. Almost every form you encounter is AcroForm.
XFA (XML Forms Architecture). Dynamic forms with conditional logic, repeating sections, and database-style behavior. Authored in Adobe LiveCycle Designer. Mostly used in government and enterprise; XFA support in non-Adobe readers is poor and Adobe is deprecating it.

For new forms in 2026, default to AcroForm. XFA is on its way out, and most non-Adobe readers struggle with it.

The standard field types

Text fields. Single-line or multi-line free text entry. Properties include:

Default value
Maximum characters
Multiline (yes/no, toggles between input and textarea behavior)
Password (renders as dots)
Comb of N characters (one box per character, for fixed-length IDs like phone numbers)
Format category (number, date, percent, currency, automatic validation and display)
Validate (custom JavaScript validation)

The workhorse field. Most forms are mostly text fields.

Checkboxes. Two-state toggles. Properties:

Export value, what gets recorded when checked (default: "Yes")
Default state (checked / unchecked)
Style, check, circle, cross, diamond, square, star

Use a single checkbox for single yes/no choices.

Radio buttons. A group of mutually-exclusive options. Properties:

Group name, radio buttons share a name; this is what makes them mutually exclusive
Export value per button, what gets recorded when each button is selected

Use radio buttons when the user can pick exactly one of a small set (e.g., 2-5) of options.

Combo box (dropdown). Pre-populated list, user picks one. Properties:

List items, pairs of (export value, display value)
Editable, can the user type a value not in the list?
Sort items

Use a combo box when there are many options (countries, states) and a dropdown is more compact than radio buttons.

List box. Like a combo box but with a visible scrollable list. Properties similar to combo box, plus:

Multiple selection, allow more than one selection

Use a list box when you want the options visible without clicking, or when multiple selection is needed.

Signature field. A field designed for digital or electronic signatures. Properties:

Signed by, once signed, who signed
Lock document on sign, make the rest of the form read-only after signing

See how to add a signature field to a PDF form for the detailed workflow.

Button. A clickable element that triggers an action. Properties:

Action, submit form, reset form, run JavaScript, navigate to URL, etc.
Appearance, text label, icon, both

Use buttons for form actions: Submit, Reset, Help, Print.

File attachment field. Lets the user attach a file when filling. Less commonly used. Properties:

Accept type, restrict to certain file types
Maximum size

Barcode field. Auto-generates a barcode encoding form data. Rare in modern forms; common in government processing pipelines.

Choosing the right type

For most forms:

Free text → Text field
Yes/no → Checkbox (single) or Two radio buttons if the wording is "yes or no"
Pick one of a few → Radio buttons
Pick one of many → Combo box (dropdown)
Pick many → List box with multi-select or multiple checkboxes
Sign here → Signature field
Submit form → Button

Beyond that:

A date → text field with date formatting
A phone number → text field with phone formatting, or a comb field for fixed-length
An amount of money → text field with currency formatting
An ID number → text field with mask or comb formatting

The choice affects both the user experience and how clean the extracted data will be. See how to export PDF form data for the downstream consequences.

Naming fields well

Every field has an internal name. This name appears in extracted data, in form scripts, and in third-party data pipelines.

Conventions:

Use English keywords without spaces. customer_name not "Customer Name"
Group related fields with prefixes. address_street, address_city, address_state, address_zip
Use hierarchy. customer.name, customer.email, most form tools support dotted hierarchical names
Avoid auto-generated names. "Text1", "Text2", "Text3" makes data extraction painful
Match the data schema that consumes the form, so field names map cleanly to database columns or JSON keys

Renaming fields after the form is published can break downstream pipelines. Pick names well the first time.

Validation

Every field type supports basic validation. Text fields support more:

Required, the field must have a value before submit
Format, numbers, dates, percentages, currency, custom regex
Range, minimum and maximum values for numeric fields
Custom JavaScript, arbitrary logic checked on field exit

See how to add validation to a PDF form for the detailed workflow.

Calculations

Numeric fields can be calculated from other fields. The most common:

Sum, total of several fields (e.g., subtotal)
Product, multiplication (e.g., price × quantity)
Simplified arithmetic, preset formulas in many editors
Custom JavaScript, anything else

A typical invoice form: each line has price × quantity = line total, the subtotal is a sum of line totals, tax is subtotal × tax rate, grand total is subtotal + tax.

See how to add calculations to a PDF form.

Conditional logic

A field that depends on another field's value (show/hide, enable/disable) requires JavaScript:

In Acrobat Pro: Properties → Actions → On field change → Run JavaScript
Use this.getField("field_name") to access another field
Use .hidden, .readonly, .required to change behavior

For example, on a customer form: "Other" radio button shows a text field; selecting any other radio button hides it.

Most full-featured forms have several conditional fields. Be careful about JavaScript portability, browser-based PDF viewers (Chrome, Firefox) and mobile readers have limited JavaScript support. Test in the readers your audience uses.

Tab order and accessibility

The order in which Tab moves between fields matters for usability and accessibility. Default tab order follows the order fields were added, which is rarely the intuitive order.

In Acrobat Pro: Tools → Prepare Form → Tab Order panel → arrange fields in the desired sequence
For accessible forms: tab order should match visual reading order

Every field should have a tooltip (accessible label) for screen readers. See PDF/UA accessibility standard explained.

Appearance and styling

Form fields have appearance properties:

Border, color, width, style (solid, dashed, beveled, underline, inset)
Fill color, background of the field
Text properties, font, size, color, alignment
Highlight, what shows on hover/focus

Acrobat Pro's "Highlight Existing Fields" command in the form viewer shades all fields in light blue, which helps users see what they need to fill. Some tools turn this on by default; some require explicit enabling.

Common gotchas

Field names with spaces or special characters. Some downstream tools handle them poorly. Stick to letters, numbers, underscores, dots.

Checkbox export value mismatch. A checkbox group with all values set to "Yes" loses information about which specific checkbox was selected. Set unique export values when checkboxes represent distinct choices.

Radio buttons with mismatched group names. Radio buttons that should be mutually exclusive but have different group names become independent toggles. Verify all radios in a group share the same field name.

Required fields that are not enforced. Some readers do not honor the required attribute on submit. For critical forms, add JavaScript validation that runs on the Submit button.

Calculated fields not updating. Acrobat's calculation order matters: a sum field depending on individual fields must come after those fields in the calculation order. Check Tools → Prepare Form → "More" → Set Field Calculation Order.

Locked signature fields. Once signed, the form is locked from further edits. Plan whether you want the form to accept multiple signatures (counter-sign workflow) or lock fully after the first signature.

Mobile readers. Form filling on mobile is uneven. Test on iOS and Android before assuming users can complete the form on a phone. See how to edit PDF on iPhone and how to edit PDF on Android.

Form data submission. The Submit button can post to a URL or generate an email. Email submission is often blocked by modern mail clients and unreliable; URL submission is more dependable.

Practical recipe

For a new form:

Plan the data schema first, what fields, what types, what names
Author the visual layout in Word, InDesign, or LibreOffice
Export to PDF
Open in Acrobat Pro / Docento.app → Prepare Form / Add Field
Drop in fields of each type
Name them per the data schema
Set required, validation, and calculations
Set tab order
Test fill the form
Submit-test or export-test the data
Publish

For more on overall form creation, see how to create a fillable PDF form and making a PDF fillable.

Takeaway

PDF form fields are a small but well-structured catalog: text, checkbox, radio, dropdown, list, signature, button, file attachment, barcode. Choose by data semantics: free input, single choice, multiple choice, action. Name fields well, set required and validation thoughtfully, and verify on the readers your audience will use. For the higher-level workflow of building a complete fillable form, see how to create a fillable PDF form; for browser-based form work, Docento.app lets you build forms in the browser without installing software.