Why a Filled PDF Form Looks Blank or Prints Empty

You fill in a PDF form, save it, open it somewhere else and the boxes are empty. Or the form looks perfect on screen and the printout has blank boxes. The data is usually still in the file; what is missing is the way it is shown. Understanding the two layers behind a form field explains almost every case.

A field has a value and a drawing

An interactive PDF form is a list of fields. Each field has a value (the text typed in, or whether a box is ticked). The field appears on a page through a widget annotation, a rectangle that has its own appearance stream: a small drawing, made of PDF instructions, of what the field currently looks like (ISO 32000-1, clauses 12.5 and 12.7). A viewer paints the drawing. When a program changes the value but does not redraw the widget, the value and the drawing disagree.

Adobe Acrobat is forgiving: it can rebuild a missing appearance from the field's default appearance string. Many browsers, phone viewers, preview panes and print pipelines draw only what is stored, so the same file shows filled boxes in one place and empty boxes in another. A form can carry a NeedAppearances flag that asks a viewer to rebuild everything on opening, but a viewer that ignores it will not.

Typical causes

• The field was filled by a script, a web service or a library that sets values without updating appearances.
• The appearance exists but draws nothing, for example after a tool cleared it.
• A check box was set to "on" but its widget still points at the "Off" drawing, or at a state that has no drawing.
• The widget is flagged Hidden, or lies outside the page area, so it is never drawn although it holds data.
• The default appearance names a font that the form does not contain, so a viewer rebuilding the field has nothing to draw with.

The PDF Form Appearance Checker goes through every field and says which of these applies to which field, on which page.

Printing follows other rules

When a page is printed, each annotation is included only if its Print flag is set, it is not Hidden, it has an appearance to draw and it lies inside the page boundary; a layer that is switched off, or set not to print, is left out (clause 12.5.3 and optional content). A field created as "visible but does not print" never reaches paper, and a field marked "no view" with Print set is a legitimate way to build a field that appears only on paper. The PDF Form Printability Checker reads these settings and marks each form element as printing, partly printing or not printing.

The two questions are separate. A field can look right on screen and not print, or print and not show. That is why they are two tools.

Fixing it

• In the program that fills the form, run its "update appearances" step before saving, or flatten the result.
• In a form editor, set the field's visibility to "Visible", not "Visible but does not print", and keep it inside the page.
• If the recipient does not need to edit the form, flatten the PDF: the values become part of the page and every viewer shows and prints the same thing.
• If the file is damaged or odd, the PDF Structure Validity Checker shows whether the file itself is sound.

Whatever you change, test in the viewers your recipients use. No checker can know how every viewer or printer driver behaves, and the print dialog's own settings can still change the result. See also how to check a PDF before sharing it.