DollarWise

Fillable PDF Form Field Naming Conventions: Checklist + Examples

October 21, 2026 · 3 min read · By the DollarWise team
Fillable PDF Form Field Naming Conventions: Checklist + Examples
On this page

Anyone who has opened a fillable PDF and found fields named text1, text2, and Check Box 14 has felt this pain. Sloppy field names turn every future edit into archaeology: which “text4” holds the email address, and will renaming it break the JavaScript that validates the form? This free checklist gives you ten fillable PDF form field naming conventions — lowercase snake_case, section prefixes, zero-padded sequences, and type suffixes — plus a good-vs-bad example table you can hold next to your own forms. It is built for form designers, operations teams, and developers who build or automate PDFs in Acrobat, pdf-lib, or any form builder, and who want forms that stay maintainable years after launch.

What’s inside this checklist

The resource has three parts. First, the ten naming rules, each stated as a single enforceable convention with a short example — snake_case everywhere, no spaces or special characters, section prefixes like billing_ and shipping_, zero-padded numbers for repeating groups, and _sig, _chk, _radio, and _date suffixes for special field types. Second, a good-vs-bad comparison table showing ten real-world renames so you can pattern-match instantly. Third, a seven-item audit checklist for reviewing forms you inherited. The rules work identically in Acrobat, pdf-lib, and every mainstream form tool because they target the names themselves, not any one product’s quirks.

Naming conventions (sample)

These samples show the pattern — a rule plus a concrete example. The full ten rules and the complete good-vs-bad table are in the free download at the bottom of this page.

  1. Use lowercase snake_case for every field: applicant_first_name — never FirstName or text1
  2. Never use spaces, dashes, or special characters — letters, numbers, and underscores only
  3. Prefix fields with their section: billing_street, billing_city, shipping_street
  4. Zero-pad sequential numbers: dependent_01_name, dependent_02_name
  5. Suffix special field types: _sig for signatures, _chk for checkboxes, _radio for radios, _date for dates
  6. Radio button groups share ONE field name; each option gets a distinct export value
  7. Independent checkboxes get unique names; grouped checkboxes share one name
  8. Never rename a field after scripts or integrations reference it
GOOD                              BAD
applicant_first_name              First Name
contact_email                     Email-Address
billing_postal_code               ZipCode
consent_privacy_chk               Check Box 14
signature_applicant_sig           SignatureField1

How to use this checklist

  1. Before building a form, copy the ten rules into your project notes or team wiki.
  2. Name every field as you create it — renaming later risks breaking scripts and integrations.
  3. Use the good-vs-bad table as a review aid: scan each name and ask which column it belongs in.
  4. For inherited forms, run the seven-item audit checklist and rename fields before wiring any automation.
  5. Save the data dictionary (field name, label, format, required or optional) alongside the finished PDF.

Good names are a one-time investment. Ten minutes of discipline during form design saves hours of debugging the day someone needs to pre-fill, validate, or export that form’s data.

Advertisement

Frequently asked questions

Why do PDF form field names matter? Field names are how scripts, integrations, and screen readers identify each field. Clean names make forms testable and automatable; names like text1 or Check Box 14 make every future change a guessing game and break the moment anyone touches the form.

Should radio buttons share a field name? Yes. All options in one radio group share a single field name, and each option gets a distinct export value. That shared name is exactly what makes the options mutually exclusive — separate names would let users select them all.

Is snake_case really better than camelCase for PDF fields? For PDFs, yes. Snake_case survives every export path without case-folding surprises, reads clearly in data dictionaries, and sorts predictably. Whatever case style you prefer in code, keep the form layer uniform.

Download the full checklist

#pdf#forms#checklist#productivity
Advertisement
Written by the DollarWise team

We turn confusing money topics into plain-English guides for beginners. Every article is written to be actionable on day one — no jargon, no hype, no sales pitch.

Keep reading