What a PDF form field actually is
Some PDFs can be filled properly and some can only be written on, and the file decides which. Here is the difference, and what to do in each case.
There are two completely different things people mean by "filling in a PDF", and which one you are doing is decided by the file rather than by you. Knowing which is which saves a lot of fighting with the wrong tool.
A form field is something the file declares
A PDF can carry an AcroForm: a structure listing named fields, each with a type, a position, and often a value. When that exists, a reader draws real editable boxes, and a tool can fill them by name — write "Ana Reyes" into applicantFullName and the value is stored as the value of that field. It stays a value. It can be read back, changed, extracted, or submitted.
Most forms that arrive by email have none of this. A form laid out for printing, or scanned from paper, is just marks on a page as far as the file is concerned — the boxes are lines in a picture, and there is nothing to fill. Nothing is wrong with the file; it simply was never a form in the sense software understands.
Which is why there are two tools
Our PDF Form Filler reads the fields a document declares and writes values into them. It needs a real AcroForm and it does nothing without one, and where one exists it is the better choice: values go exactly where the form intended, tick boxes are genuinely ticked, and nothing can be a few pixels out.
Fill & sign ignores all of that and puts text wherever you click, then flattens it into the page. It works on absolutely any PDF including a scan, and it is the only option when there are no fields. The trade is that it is drawing rather than filling: the position is wherever you clicked, and afterwards the text is part of the picture.
A reasonable rule: open the file in the form filler first. If it reports fields, use it. If it says there are none, that answer is itself the diagnosis, and Fill & sign is the tool.
Why the field names look like nonsense
Field names are written for software, not for people, and complex official forms tend to have generated ones — topmostSubform[0].Page1[0].f1_07[0] and its several hundred siblings. There is no rule that a name has to describe anything.
A filler can make a reasonable guess where the name contains words: applicantFullName becomes "Applicant Full Name". Where it does not, honesty is better than invention, which is why ours falls back to "Field 7" rather than inventing a label — and why it always shows the real name alongside. On a long form being checked against a paper copy, the raw name is sometimes the only way to be certain which box you are in.
Flatten, or keep it editable
Saving a filled form asks one real question. Keeping it editable leaves the form intact with your values in it, so a recipient can correct something — right while a document is still going back and forth. The cost is that PDF readers draw form fields slightly differently, so it will not look identical everywhere.
Flattening draws the values into the page and removes the form. It looks the same in every reader and nobody can change it, including you, so keep the original. That is usually what you want for a final copy.
Neither is a security measure. Flattening stops casual editing; it is not protection, and it removes nothing else the file carries. For that, see the metadata inspector and redaction.
Why a value can be refused
Field values are drawn with a font. Unless the form embeds one, the only fonts guaranteed to be available are the fourteen standard ones, and those cover WinAnsi — English, western European accented letters, curly quotes, dashes, the euro sign. They do not cover Greek, Cyrillic, Chinese, Japanese, Korean, Arabic, Hebrew or emoji.
So a name in a script the font cannot draw cannot be written into a standard form, and the failure in most tools is an error partway through saving. Catching it while you type is better, which is why ours names the offending characters instead. Where a form genuinely needs them it has to embed a suitable font, and that is a decision made when the form is built rather than when it is filled.
XFA: the forms nothing else can fill
Some government and banking forms are XFA — a different technology that stores the form as an XML description rather than as PDF fields. Adobe deprecated it, most readers never supported it, and no browser-based tool can fill one.
The symptom is unmistakable: the file opens showing "Please wait… if this message is not eventually replaced" and nothing else. That page is a fallback for readers that cannot render XFA, which is nearly all of them. Adobe Acrobat Reader on a desktop is the reliable route, and sometimes the only one.
Two things worth doing before you send it
Read the values back. Open the saved file and check a few fields actually contain what you typed — particularly on a form you flattened, where a mistake is no longer editable.
And look at what else is in the file. A PDF carries author names, timestamps, the software that made it, and sometimes earlier revisions of its own content. None of that appears on the page, and a filled form is usually going to someone you would rather not send it to. The metadata inspector shows what is there.