A fillable PDF is a regular PDF document that contains interactive AcroForm fields — text boxes and checkboxes — which a recipient fills in, saves, and prints without altering the original layout. The "fillable" part is not the page design or the labels printed on the paper; it is the set of named field objects embedded inside the PDF that any standard viewer recognizes. A text field accepts typed characters; a checkbox stores a checked or unchecked state. Both stay interactive until someone flattens the document, and both can be marked required so an empty response stands out. The AcroForm model is the conventional, widely supported approach used by desktop readers like Adobe Acrobat and Foxit, by browser-based PDF viewers, and by most mobile PDF apps.
The best way to create a fillable PDF form when you are starting from a blank page — not from a scanned paper form or an existing layout — is to use Create Fillable PDF, a browser-based builder that turns a short field plan into a downloadable AcroForm file in a few clicks. It is aimed at small, structured documents such as a registration sheet, feedback form, consent checklist, intake page, or request form, and it runs the whole generation step on your device so the form definition and the resulting PDF never leave your browser.
What a fillable PDF actually contains
Under the hood, a fillable PDF is a PDF file plus an interactive form dictionary. The PDF defines the pages, fonts, and visual layout; the form dictionary lists every field by an internal name, describes its type (text or checkbox), draws a rectangle on the page where the field appears, and records whether the field carries the required flag. When a recipient opens the file, their viewer reads that dictionary, places a text cursor inside each rectangle, and lets the user toggle each checkbox. When they save, the viewer writes the responses back into the same field objects, which is why the responses persist the next time the file is opened.
Two details matter for any fillable document. First, the internal field name is part of the PDF structure, so every name in a form must be unique — duplicate names make responses ambiguous when the file is later processed. Second, the visible label a reader sees printed next to the box is separate from the internal name; the label is decorative text, while the name is how software and integrations identify the field.
How to create a fillable PDF from a blank page
For a basic registration sheet, intake form, or consent checklist that does not need to follow an existing page design, the simplest workflow starts from a blank page rather than trying to retrofit an existing template. Open the builder, define a small set of fields, and download the file. The order below is the path that produces a clean result with the least trial and error.
- Open Create Fillable PDF and enter a form title. The title and visible labels accept printable English characters up to 100 characters because the file uses a built-in standard PDF font.
- Choose A4 or US Letter as the page size, depending on the paper your recipients print on.
- Add at least one field before generating. A form with zero fields is rejected, and the maximum is 30 text boxes or checkboxes combined.
- For each field, set its type (text box or checkbox), a unique internal name (English letters, numbers, spaces, underscores, or hyphens, up to 64 characters), a visible label, and an optional required flag.
- Reorder the fields so the printed order matches the order a reader is expected to fill them in.
- Generate the file and download the PDF. Changing the title, size, type, name, label, or required option clears the previous result so an old download cannot be mistaken for the current settings.
- Open the downloaded file in the exact PDF viewer your recipients will use. Type into every text field, toggle every checkbox, save a copy, close the file, and reopen it to confirm that the responses persist.
- Print or preview the pages to verify that labels and controls fit, then distribute the file.
Plan your fields before you generate
A short field plan saves a lot of back-and-forth. List the questions the form needs to ask, decide for each whether it is free text or a yes/no choice, and write a short visible label that fits the supported 100-character limit. Then assign a stable internal name to each one — short, descriptive, and unique. Internal names are the part of the file that any later automation, integration, or data export will key on, so it pays to keep them readable.
The required flag is best used sparingly. It sets the PDF required flag and adds an asterisk to the printed label, but viewers handle that flag differently: some highlight required fields, some enforce them only during a submit action, and some provide little visible indication. Mark required only on fields that genuinely block a decision if left blank — for a feedback form, for example, the respondent's role might be required while an optional comments box should not be.
Keep the total count under 30. When the current page no longer has safe vertical space, the generator adds another blank page and continues in the same field order, so a longer form simply spreads across more pages. The result summary reports the actual page and field counts so the layout can be confirmed before sending.
Text box vs checkbox: what each field actually does
The builder supports two field types and each behaves very differently inside a PDF viewer. The table below summarizes the verified behavior of each, taken from the product contract rather than inferred from general assumptions.
| Aspect | Text box field | Checkbox field |
|---|---|---|
| What the recipient does | Types characters into a single-line box that spans the usable page width | Toggles a small box on or off, sitting beside its label |
| Stored value | Free-form typed text that the viewer's text layer records | A checked or unchecked state, nothing else |
| Internal name rules | English letters, numbers, spaces, underscores, hyphens; up to 64 characters; must be unique across the form | Same naming rules as text boxes; must be unique across the form |
| Required flag effect | Sets the PDF required flag and adds an asterisk to the printed label | Same — sets the flag and adds the asterisk to the printed label |
| Best used for | Names, addresses, free-text responses, identifiers, short answers | Yes/no choices, opt-ins, multi-item checklists, confirmations |
How different PDF viewers treat the required flag
The required flag is set on the field object itself, but viewer behavior is not identical. Adobe Acrobat and most desktop readers honor the flag during form-level validation and surface a warning when an empty required field is part of a submit or export step; some browser-based viewers display a colored border or an asterisk but do not enforce the rule at all unless a submit action exists. Because the tool does not add a submit button, email action, JavaScript validation, or signature field, no viewer can stop a recipient from saving an empty required field and walking away. Treat the flag as a printed hint for the reader, not as enforced validation, and verify behavior in the actual reader the recipients will use.
Test the file before you send it
Always open the downloaded file in the exact viewer your recipients will use. Type into every text field, toggle every checkbox, save a copy, close the file, and reopen it to confirm responses persist. Print or preview the pages to check that labels and controls fit within the page. Long labels fit the supported input limit but may not suit every page design, so inspect the result before distribution. If a problem appears — a label that wraps badly, a control that lands too close to a page edge — adjust the field plan and regenerate; the generator rebuilds the file from scratch each time and does not patch the previous result.
When a basic form builder isn't the right tool
The builder creates a new document; it does not open, inspect, or modify an existing PDF. It cannot place controls over an uploaded template, recognize printed labels on a scan, or preserve an existing page design. It also does not add dropdowns, radio groups, date pickers, signature fields, calculations, accessibility tagging, custom fonts, branding, or a submit button, because the underlying library — pdf-lib's form API — produces a basic AcroForm rather than a full authoring environment. If recipients need to fill and sign a document that already has its own layout, that document has to be rebuilt in a professional authoring application and the accessibility and compliance review required for that audience has to happen there.
Two related tasks are handled by separate tools. When a filled form needs to become a permanent, non-editable record, flatten the PDF form fields in your browser so responses can no longer be changed. When a signature needs to be drawn on a document, use Sign PDF — the form builder does not embed a signature field, and flattening would lock in a placeholder the recipient never signed.
Security and handoff basics
The downloaded PDF is not encrypted, certified, signed, access-controlled, or connected to a database. Anyone with the file may copy or alter it, and entered responses remain inside each recipient's saved PDF unless they send that file elsewhere. For that reason, a blank local form should not be relied on as a secure collection system for passwords, payment card details, health records, identity documents, or other sensitive information — an appropriately secured service is needed when submissions must be collected, authenticated, retained, audited, or deleted under a policy. For a low-stakes internal handoff — a class registration sheet, a feedback round, an event checklist — the file travels as a normal attachment, the recipient fills it in their viewer of choice, and they email the saved file back.