Direct answer: keep the original PDF, upload a working copy to the PDF Form Builder, place the right field type over each blank, give every field a stable unique name, and download the new PDF. Reopen that exact download, type into every field, tab through the form, save it, and test it in the viewers your recipients use. PDFCheck adds standard AcroForm fields; it does not add signatures, calculations, validation rules, required flags, accessibility tags, tooltips, or formal compliance.
First-screen decision map
| What the person must do | Use | Example name | Avoid |
|---|---|---|---|
| Enter free text, a date, or an identifier | Text field | employee_full_name | A box too short for the longest valid answer |
| Select any number of independent choices | Checkboxes | equipment_laptop | One shared name for unrelated choices |
| Choose one option while keeping the page compact | Dropdown | primary_office | Hidden choices that need side-by-side comparison |
| Choose exactly one visible option | Radio group | working_arrangement | Independent yes/no choices in one radio group |
If people only need to complete fields that already exist, do not rebuild the form. Use the PDF Form Filler, then save and reopen a test copy before distribution. Use the builder only when blank lines, boxes, or labels are visible but not clickable.
Before you add fields: preserve and prepare the source
- Keep the original unchanged. Work on a clearly named copy such as
onboarding-form-working.pdf. Adding form fields changes the PDF and can invalidate an existing digital signature. - Confirm that the layout is final. Correct wording, page order, blank space, and labels in the source application when possible. A form field sits over the page; it does not rewrite the underlying sentence.
- Check whether fields already exist. Click or press Tab in a current PDF viewer. If the cursor moves through usable controls, test those fields instead of placing duplicates.
- Identify scans. A scanned page can receive form fields, but the underlying image still needs visual and accessibility review. Adding boxes does not OCR, tag, or repair the scan.
- Remove real data from templates. Start from a blank authorized document, not a previously completed form containing another person's details.
How to make the existing PDF fillable
1. Upload a working copy
Open the PDF Form Builder and upload only a PDF you are allowed to process. The builder opens the page in a field-placement workspace. Treat the project as temporary working material and retain your own source copy.
2. Add one text field for each distinct answer
Choose Text, click the blank area, then drag and resize the overlay. Use a descriptive name made from letters, numbers, and underscores, such as employee_full_name, work_email, and start_date. PDFCheck sanitizes field names during export, so simple names prevent ambiguous changes. Set a default value only when it is truly valid for every recipient.
3. Use independent checkboxes for “select all that apply”
Create a separate checkbox and unique name for each independent choice: equipment_laptop, equipment_monitor, and equipment_security_key. A checkbox represents its own yes/no state. Do not use checkboxes when the person must select exactly one answer.
4. Use a dropdown for one choice in limited space
Place a Dropdown, give it one stable name, and enter one option per line. Use short, unambiguous labels. A dropdown is useful for a long office or department list, but it hides choices until opened. If comparing all options matters, use a radio group instead.
5. Use a radio group for one visible choice
Place a Radio field, name the group, and enter one option per line. PDFCheck creates the group choices vertically from that placement. Leave enough space below the first control and test that no option overlaps nearby page content. Radio choices are mutually exclusive; checkboxes are not.
6. Save the field layout, then download the form
Save stores the current field layout for the active browser session; it is not the finished PDF on your device. Choose Download PDF to generate the AcroForm file. Give the download a versioned name such as onboarding-form-v1-test.pdf.
PDFCheck capability boundary: the builder adds standard text fields, checkboxes, dropdowns, and radio groups, with basic names, sizes, text defaults, font size, and choice options. It does not create signature fields, date pickers, multiline settings, required flags, validation rules, calculations, conditional logic, scripts, tooltips, field descriptions, an explicit tab order, response collection, XFA forms, or PDF/UA certification. Use a capable desktop authoring and accessibility workflow when those requirements matter.
Name fields for people, data, and future maintenance
| Weak name | Better name | Why it is safer |
|---|---|---|
Text_1 | employee_full_name | The value remains understandable outside the page layout |
checkbox | equipment_laptop | Each independent state is identifiable |
office? | primary_office | Simple characters survive name sanitization predictably |
choice_4 | working_arrangement | One radio group describes one question |
Names are not visible labels. Keep the page's human-readable question, and use the internal name to identify the stored answer. Adobe's current PDF forms guidance describes automatically detected fields and richer field properties; its InDesign form guidance recommends unique field names and moves advanced validation or calculation work to Acrobat. PDFCheck deliberately covers the simpler placement workflow.
Test the exact downloaded PDF
- Reopen the download, not the browser preview. A successful download only proves that a file was produced.
- Press Tab from the first page. Confirm every control receives focus, no decorative object becomes a field, and the order is usable. PDFCheck does not provide a tab-order editor, so a poor order may require an advanced authoring tool.
- Enter worst-case values. Test a long name, a long email, every choice, non-English characters needed by the audience, and a blank optional answer. Look for clipped or tiny text.
- Save, close, and reopen. Confirm the values and selections remain visible and editable.
- Test at least two target viewers. Include the viewer required by the receiving organization. Browser viewers, desktop apps, and portal previews can behave differently.
- Test an empty copy too. Make sure accidental default values or sample answers are not shipped to every recipient.
- Validate the final file. Use the PDF Validator as a structural screen, then test every field, button, calculation, and required viewer. A clean structural report does not prove that questions, logic, or accessibility are correct.
Failure states and recovery actions
| Failure | Likely reason | Recovery |
|---|---|---|
| The PDF was already fillable | New overlays duplicate existing fields | Return to the untouched original and test its fields before rebuilding |
| One field is missing from the download | A duplicate or unsafe field name may conflict during export | Use a unique letters/numbers/underscores name, download a new version, and retest |
| Radio options overlap the page | The group expands vertically from the placement point | Move the group upward or shorten the list; use a dropdown when space is limited |
| Typed text is clipped | The box is too narrow, short, or uses a large font | Resize the field, reduce the font carefully, or redesign the source layout |
| Tab order is confusing | Placement order does not match the reading sequence | Rebuild in logical order or use an authoring tool with explicit tab-order control |
| A portal rejects the form | It may require a specific PDF version, flattened copy, viewer, or field technology | Preserve the editable copy, read the portal rule, test the exact upload, and flatten only if explicitly required |
| An existing signature becomes invalid | Adding fields changed signed bytes | Return to the signed original and request a new preparation-and-signing workflow; inspect it with the Signature Checker |
Accessibility: adding visible fields is not enough
A usable form needs meaningful visible labels, programmatic descriptions or tooltips, logical keyboard order, sufficient contrast, document language, tags, and testing with the assistive technology your audience uses. Adobe's accessible-PDF guidance explicitly calls out field descriptions, tab order, tagging, and manual checks.
PDFCheck's PDF Accessibility Checker can screen a finished file for common issues; it does not certify PDF/UA or replace keyboard and assistive-technology testing. If accessibility is a requirement, use the PDFCheck builder only for a prototype or simple placement step, then finish the semantics in a capable authoring workflow.
When to use another workflow
- Use Acrobat, another advanced form authoring tool, or the source application for required fields, calculations, validation formats, scripts, conditional sections, signature fields, tooltips, explicit tab order, or formal accessibility remediation.
- Use a managed form platform when you need submissions, identity, routing, audit logs, approvals, or data retention controls. A downloadable PDF does not provide those services.
- Use the original document system when layout or wording is still changing. Repeatedly overlaying fields on an unstable PDF is fragile.
- Use the recipient's required tool for XFA, certified, or organization-specific forms. The pdf-lib form API used by PDFCheck works with standard AcroForm fields and does not provide XFA editing.
For terminology, the PDF Association glossary distinguishes AcroForm, XFA, digital signatures, and other PDF concepts that are often conflated. That distinction matters when a portal or organization asks for a specific form technology.
Final publish-and-send checklist
- □ The original flat PDF is preserved separately.
- □ Every visible question has the correct field type and a unique stable name.
- □ Checkboxes are independent; radio groups and dropdowns allow one intended choice.
- □ Long, empty, and non-English test values render without clipping.
- □ Tab order and keyboard operation were tested in the downloaded file.
- □ The saved file reopened correctly in the viewers recipients will use.
- □ Accessibility, signatures, portal rules, and advanced logic were handled outside PDFCheck where required.
- □ An editable master and a clearly versioned distribution copy are stored separately.
The reliable result is not merely a PDF with blue boxes. It is a versioned form whose field choices match the questions, whose names remain understandable, and whose downloaded copy has been completed, saved, reopened, and tested before anyone depends on it.