Fill AcroForm Fields

Writes values into the interactive form fields a PDF already defines, so the result is a genuinely fillable PDF rather than text painted on top of one.

Overview

There are two ways to get a value onto a PDF form. You can write it into the field the form's author defined, or you can draw text at a coordinate on the page and hope it lands inside the right box. This tool does the first. When a PDF carries real interactive fields — the standard format Acrobat and every other viewer understand — the value goes into the field itself.

That distinction shows up everywhere downstream. A filled form looks like a filled form rather than a document somebody typed over. Checkboxes actually check, radio options actually select, and because the values live in the document's form structure they can be read back out of the finished file for a review pass.

It also leaves the document usable. A recipient can open the filled PDF, correct a line, and save it — the right state for a draft going to a reviewer, or a form going out for a counterparty to complete. Filling never locks the document down; flattening is a separate step.

What It Does

When This Runs

Nothing chooses this step. It runs on every fill of a form that has interactive fields — once the values have been worked out, and before the finished PDF is stored. The same run reads the form's own field inventory, which is how it knows which fields the values did not cover.

A document with no interactive fields has nothing to write into. A flat scan has to be converted into a fillable form first, and that conversion is queued automatically when a flat PDF is uploaded.

When a package section is filled from uploaded sources with Fill Sections from Source Documents, this is the layer that puts the resulting values into the PDF.

Inputs and Outputs

Takes: the target PDF and a set of field-and-value pairs, using the field names from the extracted inventory.

Returns: the filled PDF.

Example

An insurance certificate needs to go out for a subcontractor. The form is a standard industry template with roughly 90 fields: text boxes for the insured, producer and certificate holder; checkboxes for each coverage type; radio groups for a handful of yes/no conditions; a dropdown of state abbreviations; and a policy number field capped at 25 characters.

The values go in: the insured's legal name and address into the text fields, checkmarks on the four coverage lines that apply, "occurrence" selected in its radio group, "NY" into the state dropdown, and the policy numbers into their boxes.

One policy number is 31 characters, because the carrier's reference was pasted in with a prefix. The field's 25-character cap does not hold it back — the value goes in whole. Because it overruns its box on the page, a pass then tries to shorten it and fills the form again; that pass is not applied to every field and does not always get the text inside the box, so the number can still end up overflowing. What you will not get is a note back saying it did not fit. The result is still a live fillable certificate: the producer opens it, adjusts one address line, and only then is it flattened and sent.

Limits

• The form must have fields. Flat scans and image-only PDFs have nothing to write into. A flat PDF has to be converted into a fillable form first, which is queued automatically on upload.
• Field names are frequently meaningless. Real forms are full of names like "Text12" and "Check3b". Knowing which value belongs in which field comes from the extracted inventory and the surrounding form context, not from the names alone.
• A declared character limit does not hold a value back. Where a field caps its own length, a longer value is written in full and the cap dropped so viewers do not clip it. The exception is a field whose box is divided into fixed character cells, where the cap stays.
• Nothing is reported back about individual fields. A name that matches nothing in the document is skipped in silence, and a value a field would not accept is not flagged. Three quiet failures on a 200-field form is the kind of thing nobody notices until a submission is rejected, so a form that has to be right needs checking against its source.
• A failed step is skipped, not raised. If writing a particular field goes wrong, or the pass that keeps the output editable in browser viewers does, the fill carries on and the document ships without it. The result looks like an ordinary filled PDF.
• Fields you supply no value for are emptied. A fill writes what it is given and clears everything else, so a form that arrived with values already in it does not keep them.
• The form's own typeface and text size are not preserved. Text is written at a size held with the form, and in a standard font whenever the field's own font is not one viewers can be relied on to render. A filled form can look different from the blank it came from.
• Dynamic XFA forms never reach this step. Some government and enterprise forms use a dynamic layout format rather than standard interactive fields, and such a document is refused when it is uploaded.

FAQ