AcroForm supports seven core field types defined in the PDF specification:

**Text field** — A single-line or multi-line input where the user types free text. Text fields can enforce a maximum character length, a specific format (date, phone number, ZIP code), and a font for display.

**Checkbox** — A boolean toggle. Multiple checkboxes on a page can be independent or grouped. A checkbox exports a name/value pair when checked and nothing when unchecked.

**Radio button** — A group of mutually exclusive options. Clicking one radio button in a group deselects all others. Radio buttons in the same group share a field name; each option has a distinct export value.

**List box** — A scrollable list from which the user can select one or multiple items. The available options are stored in the field's /Opt array.

**Combo box (dropdown)** — A collapsed list that expands on click. Unlike a list box, it can optionally allow the user to type a custom value not in the list.

**Push button** — A clickable button that triggers a JavaScript action, submits the form, resets all fields, or opens a URL. Push buttons have no persistent value.

**Signature field** — A placeholder for a digital or graphical signature. When signed with a digital certificate, the field contains a cryptographic signature that can verify document integrity.

Field values in an AcroForm are stored in the PDF's object graph under the document's /AcroForm dictionary. Each field is a PDF annotation object of subtype /Widget. The /Widget annotation defines the visual appearance of the field (its rectangle, border, background, and font) while the field dictionary defines its data properties (name, type, value, and flags).

When you save a filled AcroForm PDF, the current values are written back into the field dictionaries. This means the data travels with the file — you can share the filled PDF and the recipient will see your values without needing a separate data file.

Alternatively, form data can be extracted and submitted independently. AcroForm supports three submission formats: FDF (Forms Data Format), XFDF (XML Forms Data Format), and HTML form submission. These allow a server to receive just the field name/value pairs rather than the entire PDF, which is useful for backend processing.

PDF contains two entirely separate form technologies. AcroForm (described here) is the original and is defined in the core PDF specification. XFA (XML Forms Architecture) is a later addition, introduced by JetForm Corporation and later acquired by Adobe, that embeds an XML-based form description inside the PDF.

XFA forms are dynamically laid out — the form can add or remove pages based on the data entered, and fields can reflow like a web page. This power comes at a cost: XFA is only fully supported by Adobe Acrobat and a handful of specialist viewers. Chrome, Firefox, Apple Preview, and most PDF libraries do not render XFA forms at all.

For this reason, XFA has been officially deprecated in PDF 2.0. Adobe itself recommends converting XFA forms to AcroForms. For any form intended to work on the widest range of devices, AcroForm is the right choice.

Once a user has filled in an AcroForm, you may want to "flatten" it — merging the field values permanently into the page content so they can no longer be edited. Flattening is useful when:

- You need to send a finalised document where the values cannot be changed - You are archiving the form in PDF/A format, which does not allow interactive fields - You want the values to be visible in viewers that do not support form rendering

After flattening, the form fields no longer exist as interactive objects. The text the user typed appears as ordinary text drawn on the page, and checkboxes appear as static marks. The PDF behaves like a normal non-interactive document. PDFTheGuide's fill-form tool lets you fill and download AcroForm fields; the downloaded PDF embeds your values directly into the page.