Half the forms sent as "fillable" are not. They are flat pages that happen to have lines drawn on them.
Fields versus typing on top
A form field is an interactive object with a name, a type and a value. It can be tabbed between, validated, exported as data, and filled in by essentially any reader including on a phone.
Typing on top is an annotation — a text box floated over the page. It looks similar on your screen and behaves completely differently: no tab order, no validation, no data export, and crucially many mobile PDF readers cannot create annotations at all.
That last point is why forms come back empty. Someone opens your "fillable" PDF on a phone, finds no way to enter anything, and either prints it or gives up. Roughly half of all document opens are on mobile now, so a form that only works on desktop is a form half your recipients cannot complete.
Field types and when to use them
| Type | Use for | Watch out for |
|---|---|---|
| Text field | Names, addresses, free text | Set a sensible max length |
| Checkbox | Independent yes/no options | Each is separate; any combination allowed |
| Radio group | Mutually exclusive choice | Cannot be unchecked once set |
| Dropdown | One of many known options | Long lists are painful on mobile |
| List box | Multiple selection | Poor mobile support |
| Date field | Dates | Format varies by locale; label it |
| Signature field | Signing | Needs a reader that supports it |
The radio group row is the one people report as a bug. Radio buttons in a group are mutually exclusive by design and, in most readers, cannot be returned to unselected once a choice is made. If "none of these" is a valid answer, it needs to be an explicit option in the group — or the field should be checkboxes instead.
Build the layout first
The order matters, and getting it wrong means doing the work twice.
Design the whole document — text, lines, boxes, labels — and export it to PDF. Then add the fields on top of the finished page. If you add fields first and then change the layout, every field is now in the wrong place, because a field is positioned by coordinates and does not move with the content beneath it.
- Finalise the layout in Word, Docs or a design tool, and export.
- Add fields in a PDF editor. Most will auto-detect likely field positions from underlines and boxes, which is a good starting point and always needs checking.
- Name every field meaningfully.
applicant_surname, notText1. This is what exported data looks like, and what anyone processing the responses has to work with. - Set the tab order. Default order follows creation, not layout, so a form built out of sequence tabs around the page unpredictably.
- Test on a phone before sending. Not optional.
What makes a form work on mobile
Mobile readers implement a subset of the form specification, and the gaps are consistent enough to design around.
- Field size. A field sized for a mouse is hard to tap. Aim for at least 40px of height at 100% zoom.
- Avoid list boxes and long dropdowns. Support is patchy and the interface is cramped.
- Avoid JavaScript validation. Most mobile readers ignore embedded form scripts entirely, so a form that depends on them for calculations or required-field checks silently loses that behaviour.
- Keep it to one column where you can. Side-by-side fields force horizontal panning.
- Do not rely on the tab key. There is no tab key on a phone; people tap fields directly, so the visual order has to make sense on its own.
The JavaScript point is worth taking seriously for anything with calculated totals. If the arithmetic only happens in Acrobat, half your submissions will arrive with the total blank or wrong.
Locking a completed form
Once a form is filled in, the values are still editable by anyone who opens it. For a signed agreement or a submitted application, that is usually not acceptable.
Flattening merges the field values into the page content. The text stays visible and stops being a field, so nobody can change the answers or clear them.
Flatten after filling and before sending, and keep the unflattened original if you might need to correct it. Note the ordering with signatures: fill, flatten, then sign. Signing first and flattening afterwards invalidates the signature, because flattening changes the file — the reasoning is in how to sign a PDF electronically.
Getting the data out
The point of real form fields, beyond usability, is that the answers are data rather than pixels.
A PDF form can export its values as FDF, XFDF or CSV, and a batch of returned forms can be merged into a single table. That turns fifty returned applications into a spreadsheet rather than fifty documents someone has to read and retype.
This is entirely lost if people type on top instead of using fields, and it is the strongest practical argument for building the form properly. If the answers matter enough to collect, they matter enough to collect as data.
Frequently asked questions
Why can people not fill in my PDF on their phone?
Because it is not a real form — they are being asked to add annotations, and many mobile readers cannot create them. Real AcroForm fields work almost everywhere including on phones. Around half of document opens are mobile, so this halves your completion rate.
How do I uncheck a radio button?
In most readers you cannot — radio groups are mutually exclusive by design and do not return to unselected. If "none of these" is a valid answer it needs to be an explicit option in the group, or the field should be checkboxes instead.
Should I add fields before or after designing the page?
After. Fields are positioned by coordinates and do not move with the content beneath them, so changing the layout afterwards leaves every field in the wrong place. Finalise the design, export, then add fields.
Why do my calculated totals not work for some people?
Because they rely on embedded JavaScript, which most mobile readers ignore entirely. Anything depending on scripts for calculation or required-field validation silently loses that behaviour outside Acrobat.
How do I stop someone editing a completed form?
Flatten it, which merges the field values into the page so they are visible but no longer editable. Keep the unflattened original in case you need to correct something. Fill, flatten, then sign — signing before flattening invalidates the signature.
Can I get the answers out as a spreadsheet?
Yes, if you used real form fields — a PDF form exports values as FDF, XFDF or CSV, and returned forms can be merged into one table. This is impossible if people typed on top, which is the strongest reason to build the form properly.