PDF forms are everywhere: tax returns, insurance claims, onboarding paperwork, building permit applications, academic enrolment forms. When designed well, a PDF form is a seamless experience — users tab through fields, validate their entries, sign, and submit. When designed poorly, the form is an exercise in frustration: fields that skip the wrong way, validation messages that appear without explanation, and forms that look perfect in Acrobat but break in Preview on Mac. This guide covers the principles and practical techniques behind well-designed PDF forms — from the choice of form technology (AcroForm vs XFA) through field types, tab order, accessible labelling, validation, and signature fields, to distribution and submission workflows.

AcroForm vs XFA: which technology to use

PDF forms exist in two fundamentally different technologies: **AcroForm** (introduced in PDF 1.2): The original and universally supported form model. AcroForm fields are PDF objects within the document's interactive forms dictionary. They render natively in all PDF readers that support forms, are supported by the PDF specification, and will continue to work for the foreseeable future. **XFA** (XML Forms Architecture): An XML-based form engine embedded inside a PDF wrapper. Developed by Adobe's JetForm acquisition and supported in LiveCycle Designer. XFA forms can have dynamic behaviour (showing/hiding fields, calculating values, reflowing layout), but require Adobe Reader/Acrobat to render correctly. Most non-Adobe readers (PDF.js, Preview, Chrome's viewer) cannot render XFA forms — they either show a blank page or display an error message. **Recommendation**: Use AcroForm for all new forms. XFA was deprecated in PDF 2.0 (ISO 32000-2) and is being phased out. If you need dynamic form behaviour, implement it with AcroForm JavaScript actions or use an HTML form instead.

Field types and when to use them

AcroForm supports the following field types, each defined in ISO 32000: **Text fields** (/Tx): Single-line or multi-line text input. Use multi-line for addresses, notes, and descriptions. Set maximum length where appropriate to prevent database overflow. **Checkbox fields** (/Btn with pushbutton=false): Boolean on/off choices. Use for independent options (multiple selections allowed). Do not use for mutually exclusive choices. **Radio button groups** (/Btn with radio=true): Mutually exclusive choices within a group. All buttons in a group share the same field name; each has a distinct export value. **Dropdown lists** (/Ch with combo=true) and **list boxes** (/Ch with combo=false): Present a predefined list of options. Dropdowns save space; list boxes allow multiple selection. **Signature fields** (/Sig): Reserved areas for digital or ink signatures. Should be placed at the end of the form and locked after signing. **Button fields** (/Btn with pushbutton=true): Trigger JavaScript actions (submit, reset, calculate). Use for form submission and field reset.

Tab order and keyboard navigation

Tab order determines the sequence in which fields receive focus when the user presses Tab. A logical tab order follows the reading order of the document — top to bottom, left to right within each row. Illogical tab order is one of the most common usability failures in PDF forms. AcroForm tab order is set at the page level via the /Tabs entry in the page dictionary. The options are: - /R (row order): fields ordered by their vertical position on the page, then horizontal - /C (column order): fields ordered by horizontal position, then vertical - /S (structure order): fields ordered according to the document's logical structure tree (best for tagged PDFs) - Explicit order: specified in the /Kids array of the AcroForm's field tree In Acrobat Pro, use Forms > Edit Form > Tab Order to manually set the order. For complex multi-column forms, always verify the tab order by tabbing through the form after export.

Field labelling and accessibility

W3C WCAG 2.1 Technique PDF12 requires that form fields have accessible names — labels that a screen reader can announce when the field receives focus. Without an accessible name, a screen reader user hears only "text field" or "checkbox" with no indication of what information is requested. AcroForm fields support three label mechanisms: 1. **Tooltip** (/TU): The primary accessible name. Appears as a tooltip in visual viewers and is read by screen readers. Always set this. 2. **Partial field name** (/T): The internal name used in JavaScript and data extraction. Should be meaningful (e.g. "firstName", not "field1"). 3. **Alternate description** (/Alt): Additional accessibility description. For fields preceded by visible label text in the document, also ensure the structure elements correctly associate the label with the field using /Label structure elements. Acrobat's accessibility checker verifies label associations.

JavaScript validation and calculation

AcroForm supports JavaScript actions at the field level for validation, formatting, calculation, and keystroke handling. Common uses include: **Validation**: Reject non-numeric input in number fields, validate email format with a regex, enforce minimum/maximum values. Use the field's Validate action (triggered when the field loses focus). **Formatting**: Format a telephone number as (555) 555-5555 as the user types. The keystroke action fires on each keypress; the format action fires on blur. **Calculation**: Auto-populate a total field from quantity × unit price. Calculation order matters — Acrobat evaluates calculations in the tab order by default. For complex calculations, set explicit calculation order in Acrobat Pro. **Caution**: JavaScript actions in PDFs are a historic attack vector for malware delivery. Many enterprise environments disable PDF JavaScript. Do not rely on JavaScript for security validation — always re-validate data on the server. See the annotation security guide for context on PDF script risks.

Digital signature fields and document locking

Signature fields should be placed at the end of the form and should be the last fields in the tab order. After a document certification signature is applied, any changes to the document invalidate the signature — so the form must be completely filled before signing. For forms requiring multiple signatories, use separate signature fields for each signer. Define signature field lock dictionaries to specify which fields can be filled after each signature is applied, allowing sequential signing without signature invalidation. For forms distributed to users without Acrobat Pro, consider enabling "Extended Document Rights" (Reader Extensions) so that Adobe Reader users can save a filled copy — without this, Reader users can fill but not save the form. This requires a commercial Adobe licence for widespread distribution.
A well-designed PDF form is invisible to the user — they move through it naturally, receive clear validation feedback, and complete it without confusion. Achieving this requires deliberate choices at every stage: field type selection, logical tab order, accessible labels, validation scripts, and correct signature field configuration. Use our PDF form filling tool to fill and download AcroForm PDFs directly in the browser. For adding new fields to an existing PDF, our editor supports form field placement.