How to fill a PDF form online

Fill in a PDF Form or Application Online

Someone sent an application form as a PDF and wants it back filled in. What happens next depends entirely on what they actually sent: two documents that look identical on screen are handled by different tools, and a good share of failed attempts start with picking the wrong one.

A form and a picture of a form are different documents

Inside a PDF, a fillable form is a separate structure: the document carries a list of fields, each with a name, a type and coordinates on the page. Files like that come out of Word with content controls enabled, out of form builders, and out of record-keeping system exports.

A printed and scanned form has no such structure. It is a page of pixels where the ruled lines and the little boxes are drawn exactly the way the letters are.

pdf-filler only works with the first kind. It does not paint text over the page and does not guess where a ruled line sits in an image: it writes values into fields the document already has. If there are none, the panel says so plainly, and running the tool returns the file unchanged, an exact copy rather than an error.

For the second kind there is edit-pdf, where a text block goes anywhere on the page. Marks and notes laid over a finished document belong to annotate-pdf.

Working out which kind you have is faster than reasoning about it: upload the file and see whether a list of fields appears.

Why the list says `applicant_surname_1` instead of "Surname"

The fields are read out in your browser, before the file is sent anywhere for processing. Every field found becomes its own row carrying two labels: the field's name and the number of the page it sits on.

The name shown is the one the form's author gave it. The tooltip a person sees hovering over the field in an ordinary reader is not used at all. So the row matching the box labelled "Surname" on the printed form may read `applicant_surname_1`, `txtLastName` or `f1_04[0]`.

That leaves two things to match on: the page number and the order. Fields appear in the order they are stored in the document, which in a carefully built form follows the reading order down the page. Keeping the original PDF open beside the list settles almost every question.

Identical names inside one document collapse into a single row. A radio group with five circles on the page sharing one name shows up as one control listing five values, not as five separate rows.

If parsing the fields in the browser fails, the panel is replaced by a notice and the tool's ordinary parameters keep working: field discovery is a convenience, not a required stage.

How to fill the form in

1. Open pdf-filler and upload the form. 2. Wait for the field list and match it against the document by page number. 3. Type the values. Touch only the fields you are changing. 4. Decide whether the form should stay editable, covered below. 5. Run the job and download the result. 6. Open the downloaded file and read what you typed with your eyes rather than from memory.

That last step is not a formality. The value always lands in the field, but it is drawn in whatever font the form's author chose, and that is where surprises live.

Only the fields you touched are written

Just the fields you edited go into the document. The rest keep the values that were in the file to begin with, so a partly completed form is not wiped out because you added two lines to it.

The reverse holds too. Touch nothing and the tool honestly hands back a copy of the original. The panel warns about exactly that case at the bottom of the list: zero fields filled, the PDF will be saved unchanged.

What flattening actually does

The flatten switch is on by default, and the gap between its two positions is wider than it looks.

Switched on, this is not an edit lock but a genuine melting down: after processing the document's field list is empty and what you typed has become as much a part of the page as the printed text of the form. Measured on a small application form: 6559 bytes with flattening and not one field inside, 6946 bytes without it and both fields still there.

Switched off, the document additionally gets a flag telling readers to redraw the values themselves. Without that flag some programs show a filled field as blank even though the value is there in the file.

There is one trap here, and it is not obvious: flattening applies only together with filling. Uploading someone's empty form, typing nothing and getting a frozen document back will not happen; the form comes back live, with the same fields. The tool deliberately leaves alone the fields you never touched.

Strict matching against tolerant matching

The second parameter decides what to do with a field name the document does not have. Tolerant matching is the default.

Through the panel the difference is nearly invisible: the names come from the document itself and cannot drift apart. It shows up when a saved set of values is replayed against a form that has since been updated and a field renamed. Tolerant matching then hands over a document quietly missing one line, with a warning naming it; strict matching hands over nothing and names the reason.

For batch work on contracts the second option is usually cheaper: a missing file gets noticed immediately, a missing line inside a file gets noticed by the recipient.

When the form's font has no letters for your script

The value is written into the field as given, but it will be drawn in the font the form's author declared. If that font is one of the standard ones, its character repertoire is narrow, and letters outside it have nowhere to come from.

Tested on a form using a standard font: the value `Ivanov` reads back out of the finished file as `Ivanov`, while the same surname in Cyrillic reads back as `??????`. Nothing breaks and no error is reported, because as far as the document is concerned everything was written correctly.

Forms built abroad for a single script behave this way, and so do older government templates. No tool setting cures it: either fill the form in the script it was built for, or lay the text over the page with edit-pdf, where the font is your choice.

The practical rule follows. Open and look at the first form you fill in with accented or non-Latin characters, and after that you can work through the rest of that template calmly.

Checkboxes, radio buttons and dropdowns

A PDF checkbox is not built as a yes or no. It has its own name for the checked state, invented by the form's author: most often `Yes`, but `On`, `1` and meaningful names like `Male` all turn up.

In the panel none of that needs thinking about: you click the box and the right state is taken from the document. It matters to anyone calling the tool programmatically. The values `yes`, `true`, `on`, `1` and `x` resolve to the checked state, while `no`, `off`, `0` and an empty string resolve to the unchecked one. Anything outside those lists is accepted without complaint and leaves the box clear.

Dropdowns and radio groups are simpler: the permitted values come from the document, so the only thing you can choose is something it already declares.

What cannot be filled in

A document locked with an open password cannot be processed; the job stops and asks for the password. Lift the protection with unlock-pdf and come back. A password that only restricts printing or copying does not get in the way of filling.

If not a single matched field could be written, the tool will not pass the original off as a result: it stops with an error. When some pages worked and others did not, you do get the file, together with a warning saying on how many pages the values may have failed to land.

A completed application usually has to be signed next. Signatures live in sign-pdf, drawn with the mouse or uploaded as an image. Order matters here: fill in with flattening on first, sign second, or the signing step works on a document whose fields are still live and whose content can be rewritten afterwards.