Fillable PDF vs flat PDF

What flattening actually does

The PDF standard, ISO 32000, describes an interactive form, sometimes called an AcroForm, as a collection of fields for gathering information from the user. Each field is defined by a field dictionary, and its look on the page comes from widget annotations attached to it. Flattening is a feature of PDF software rather than a term in the standard: the tool draws each field's current appearance permanently onto the page and removes the field itself. The page looks the same afterwards, but the boxes are now ordinary marks. The standard also has a read only flag, which stops a field being changed while keeping it a field, and that is a lighter alternative when the value should stay but the structure should not be lost.

Which to send and which to keep

The simple rule is fillable out, flat back in. A blank form sent as a fillable file lets people type neatly, save and return it without a printer. A completed form filed as a flat copy keeps what was entered from being edited by accident, and it displays the same in every viewer, including ones that handle form fields poorly. Neither kind proves anything on its own, though. A flat file can still be altered in an editor, and nothing inside it records that it was. When a document needs to show that nobody has changed it since a point in time, that is the job of a digital signature, not of flattening.

How signing interacts with the choice

Signing sits awkwardly between the two. In the standard, filling in existing fields and signing are both actions a document can permit, and a signature field in the PDF sense is reserved for a cryptographic signature rather than a drawn name. So a fillable form can be designed so the fields are completed first and a signature applied last, with any later change to the fields detectable. A flat form relies on the visible mark alone: a drawn or stamped signature image, or ink on a printed copy scanned back in. If the signed copy must stand up to scrutiny, decide the signing method before choosing the file type, because it constrains the rest. A form that will be signed with a stylus on a tablet and one that will be printed, signed and scanned need different layouts, and neither suits a signature applied by software.

Accessibility on each side

A fillable form is only accessible if its fields are built properly. The W3C technique for PDF forms requires that each field exposes a name, role and value to assistive technology, and it specifies that the accessible name comes from the field's tooltip rather than its internal name, a detail that is easy to miss when a form is exported from another tool. A companion technique on labels makes the same point from the other side: a visible label printed beside a box is not enough, because the tooltip entry in the field's dictionary is what assistive technology actually announces. A flat form has nothing to fill at all, so a screen reader user needs another route, typically a web form, and a scanned flat form with no text layer is unreadable to them entirely. Where the PDF is the only way to respond, test it with a screen reader before sending it to the public.

The three PDFs a form can produce here

This form builder produces three different PDFs. The blank template PDF is a flat copy of the empty form for printing, and it is not gated by plan. The response PDF turns one submission into a flat document with the answers in place. The fillable PDF export creates real form fields that people can type into, and it is available from the Starter plan up; a free account is refused. All three are built on a queue rather than in the browser, so a long form takes a little while to come back. A fillable file emailed back is a file, not a submission, so it never appears in the responses table.

Questions people ask