Skip to main content
All posts
edit forms PDF API

Fill a PDF Form and Flatten It

Fill AcroForm fields by name, check the values before you write them, and flatten the form so the answers cannot be changed — in the editor or with one API call.

PodPDF Team September 17, 2026 4 min read

A form you have been sent is rarely a form you want to fill by hand. The application arrives as a PDF, the same twelve fields need the same twelve answers, and doing it in a viewer means clicking through every one of them and hoping you did not miss a box.

PodPDF’s editor now reads the form and gives you the fields.

What the editor shows you

Open a document with form fields and a Form tab appears. It is built from the document itself, not from a fixed list, so it shows whatever form you uploaded: text boxes, check boxes, radio groups, dropdowns and list boxes, each with the options it actually offers.

Fields are grouped by the page they sit on, because the editor is a page-by-page walk and the field you want is usually on the page you are looking at.

Only the fields you change are saved. A half-completed form that arrives with someone else’s answers already in it keeps them — nothing is rewritten because it happened to be on screen.

Read-only fields are shown, greyed out, rather than hidden. A form that looks shorter than it is sends you hunting for a field that was there all along.

Values are checked before they are written

A viewer will often take a value it cannot really use and quietly correct it. Type fourteen characters into a field that holds eight and you may never be told. PodPDF refuses instead, before anything is saved:

  • An option the field does not offer comes back with the list it does offer
  • Text past the field’s maximum length is refused with the limit and the length you sent
  • A line break in a single-line field is refused
  • A read-only field is refused rather than silently unlocked

You find out while you are still editing, not when someone tells you the form came through blank.

Filling with the API

Field names are fully qualified and come straight from /pdf/inspect, so a survey round-trips into a fill with nothing to translate:

{
  "op": "form.fill",
  "fields": {
    "applicant.name": "Ada Lovelace",
    "agree": true,
    "country": "Ireland",
    "languages": ["English", "Welsh"]
  }
}

Text takes a string, check boxes true or false, radio groups and dropdowns one option, and list boxes one option or several.

Non-Latin answers work

The text you see in a filled field is drawn into the document when it is saved, and the font for that is chosen while the recipe is being checked. A name in Cyrillic or Greek is drawn properly rather than failing at the last moment.

That is worth saying plainly because it is a common way for form filling to go wrong elsewhere: the value is stored, the appearance is not, and the field looks empty until someone clicks it.

Flattening: making the answers permanent

A filled form is still a form. Anyone who opens it can change the answers, and the values are still data a viewer will happily edit.

When you want a finished document, flatten it. The values become part of the page — visible, no longer editable, no longer extractable as form data:

[{ "op": "form.fill", "fields": { "applicant.name": "Ada Lovelace" } }, { "op": "form.flatten" }]

In the editor it is a button on the Form tab, and it runs after any fills you added, whatever order you added them in.

Flattening cannot be undone, and the editor says so. There is no way back to an editable form from a flattened one, so keep the original if you might need it.

Two things it deliberately will not do. It leaves signature fields alone, because drawing one onto the page would misrepresent it. And it leaves sticky notes alone: a reader draws their icon, so there is no artwork to burn in, and throwing the note away would lose its text with no trace. Both are reported rather than silently skipped.

XFA forms

Some forms — usually produced by Adobe LiveCycle — keep their fields in an XML payload rather than in the PDF’s own form structures. PodPDF refuses those outright rather than filling half of them. You will get a clear PDF_XFA_FORM error, and inspecting one never damages the payload.

Limits

One document at a time, up to 200 pages and 150 MB, with up to 200 changes in a single save. A form with hundreds of fields fills comfortably inside that — the whole thing is one operation, and one save is one charge however many fields it writes.

edit forms PDF API
Back to blog

PodPDF is built by XAD Labs, which builds custom PDF processing pipelines at scale.

Start generating PDFs today

$0.005 per PDF on a monthly plan, or $0.01 from one-off credit packs.