PDF Form Fields Won't Fill? Flat Forms, Permissions, and Preview Bugs
Clicking does nothing — or every keystroke vanishes. PDF forms fail for three boring reasons: no fields under the boxes, permissions saying no, or a viewer that can't hear you.

You downloaded the form, opened it, clicked the first box — and nothing happened. Or worse: you typed, it looked filled, and after save-and-reopen everything's blank again. Form failures are almost never "the PDF is cursed." They're one of three mechanical issues.
Cause 1: It's not a form — it's a picture of a form
Scanned forms, print-to-PDF exports, and Word forms saved without field objects produce flat PDFs: rectangles drawn on the page, no AcroForm fields underneath. Clicks land on artwork.
Test: click inside a box — no caret, no highlight, Tab doesn't jump. Hover: sometimes the entire row lights up as one blob (it's an image, not a field).
Fix paths:
- Get the true fillable original from the issuer (best);
- Use an editor's "add text field / annotate" mode to type on top (works, but values are annotations, not field data — see flatten realities);
- Print a paper copy if the form demands field-level integrity you can't fake.
Cause 2: Permissions say no
A PDF can open fine while form filling is disabled by permission flags — the owner/permission layer, not encryption of content (password types). Compliant readers gray out fill; some don't even gray, they just ignore keystrokes.
Test: Document Properties → Security. If "Changing the Document" / filling is restricted, that's your answer.
If it's your file: re-protect with filling allowed (protect guide — fill permission is an advisory flag for compliant readers). If it isn't your file: ask the sender for an unlocked/fillable copy. "Unlocking" someone else's restricted form without authorization is bypassing their controls — out of scope, ethically and often contractually.
Cause 3: Your viewer is the problem
Field support varies:
- Browser built-ins — fine for basic AcroForms, weaker on legacy XFA;
- macOS Preview — known to demand owner passwords on permission-locked forms when you only meant to fill;
- Old desktop readers — stale field engines miss newer appearance streams.
Test: open the same file in a second app. If app B accepts input, the PDF was never broken — switch apps or update. Only when every viewer fails should you suspect field corruption; then get a fresh copy (integrity checks).
Save-then-blank: the other classic
You filled fields, saved, reopened — empty. Usual causes: you closed without saving (apps lie about autosave state), you filled in a view-only annotation layer that wasn't persisted, or you reopened the original instead of the saved output. Habit: save to a new filename, close fully, reopen that file, spot-check three fields before you leave the desk.
Flatten when the form is done
Filled and final? Flatten converts fields to static page content — values print exactly, nobody can silently re-edit answers, and viewers without field support still show what was entered. Flatten after filling and before signatures you care about (or per your signature workflow — sign-last still rules: signature validity). Then the pre-send checklist catches the rest.
Frequently asked questions
Why can't I type into the PDF form fields?
Three main causes, check in order: the file is flat (a picture of a form with no field objects), permissions disallow form filling (owner/permission flags — content opens but fill is blocked), or your viewer doesn't render AcroForm fields well. Test in a second viewer immediately to split 'file problem' from 'app problem.'
How do I tell if a PDF form is actually fillable?
Click a field: a text caret or highlight means fields exist. Tab should jump between fields. Hover highlighting across the whole 'field line' often means flat artwork. Properties → Forms in an editor shows whether AcroForm fields are present. If nothing responds in any viewer, it's flat — see the flatten guide for why forms end up that way.
Can I fill a form that has permission restrictions?
If the creator cleared the fill-forms permission, compliant readers block input while still displaying the file. If you own the file, re-save with filling allowed ([password types](/blog/pdf-owner-password-vs-user-password)). If you don't, ask for an unlocked copy — bypassing someone else's restrictions isn't the move. BytesPDF Protect sets fill permissions as advisory flags for files you control.
Why does macOS Preview demand a password when I try to fill this form?
Known Preview behavior with permission-restricted forms: it asks for the owner password even when you only need to fill fields. Workarounds reported by users: open in another app (Acrobat, browser viewer), or print-to-PDF a fresh copy and fill that (structure permitting). The file may be fine; the app's security UX is strict.
Browser PDF viewer won't accept my input — is the file broken?
Not necessarily. Built-in viewers differ in AcroForm support (especially XFA-era forms). Try a desktop reader before concluding the PDF is damaged. If *no* app accepts input and the field rectangles are visible, suspect field structure — get a fresh copy or a flat version you can annotate on top of.
Related comparisons
Source-led comparisons written by BytesPDF, with the conflict of interest disclosed on each page. They link official provider documentation rather than fabricated tests.