You are designing a PDF form for client intake. If the client selects "Individual" as the account type, the form should show fields for their name and Social Security number. If they select "Business," the form should show fields for the company name and Employer Identification Number instead. In a paper form, you would print both sections and write "If applicable" next to each one. In a digital PDF, conditional logic can hide the irrelevant section entirely, showing the user only the fields they actually need to fill out.
Conditional logic in PDF forms is real and functional, but it comes with important caveats. Unlike web forms, where JavaScript and CSS provide flexible control over visibility and layout, PDF conditional logic is constrained by the PDF format's limited JavaScript implementation and the inconsistent way different PDF viewers execute scripts. Understanding what is possible and what is not prevents you from designing a form that works in your testing environment but breaks for half your recipients.
What Conditional Logic in a PDF Form Can Actually Do
PDF conditional logic runs on Acrobat JavaScript, a simplified version of JavaScript that has been part of the PDF specification since the early 2000s. It can show or hide form fields based on user input. It can enable or disable fields, change their color or border, mark them as required or optional, and populate their values from lookup tables. It can validate input as the user types, display warning messages, and trigger calculations when certain conditions are met.
What it cannot do is restructure the page layout. Hiding a field removes it from view, but the space it occupied remains. The fields below do not slide up to fill the gap. The page does not reflow. This is the single biggest difference between a PDF Forms and a web form, and it is the source of most disappointment when someone tries to replicate a web form experience inside a PDF. If your conditional logic needs to dramatically change the page layout, a PDF is the wrong tool. If it needs to show or hide a few fields within a fixed layout, PDF conditional logic handles that well.
How to Set Up a Show-Hide Rule Based on a Dropdown or Checkbox Selection
The most common conditional pattern is a dropdown or set of radio buttons that controls which subsequent fields are visible. In WukongPDF's form editor, start by creating the controlling field, the dropdown or radio button group whose value determines what happens next. Give it a clear name like "accountType." Then create all the fields that might be shown or hidden. Every possible field needs to exist on the form from the start. Conditional logic only controls visibility. It does not create or destroy fields.
With the fields created, open the controlling field's properties and locate the Validate or On Blur event tab. This is where you write the JavaScript that responds to the user's selection. A simple show-hide script looks like this: var choice = event.target.value; this.getField("ssnField").display = (choice === "Individual") ? display.visible : display.hidden; this.getField("einField").display = (choice === "Business") ? display.visible : display.hidden; When the user changes the dropdown, the script runs, checks the selected value, and sets each field's display property to visible or hidden.
An important detail: set the initial state of all conditional fields to match the default value of the controlling field. If the dropdown defaults to "Individual," the SSN field should start visible and the EIN field should start hidden. If the fields start in the wrong state, the user sees both or neither until they interact with the dropdown for the first time, which looks broken. The initial state and the script logic must agree.
Validation Rules That Check Input Before the User Moves On
Conditional logic extends beyond visibility to input validation. A date field can check that the entered date falls within an acceptable range. An email field can verify that the input contains an @ sign and a domain. A phone number field can require exactly ten digits. Validation scripts run in the field's Validate event, which fires when the user attempts to leave the field. If the script calls event.rc = false, the focus stays on the field and the user cannot proceed until the input is corrected.
A practical phone validation looks like this: var phone = event.value.replace(/\s|-|\(|\)/g, ''); if (phone !== "" && !/^\d{10}$/.test(phone)) { app.alert("Please enter a 10-digit phone number."); event.rc = false; } This script strips spaces, dashes, and parentheses, then checks whether the remaining characters are exactly ten digits. If the field is empty, validation passes, because not every phone field is required. If the field has content but it is not ten digits, the script shows an alert message and blocks the user from leaving the field.
Validation rules should be used sparingly and with clear error messages. A form that blocks the user at every field with cryptic alerts creates frustration. A form that validates only the fields where incorrect input would cause real problems, and explains what the user needs to fix, creates confidence. The alert text should state exactly what is wrong and how to fix it. "Invalid input" is useless. "Phone number must be 10 digits without spaces or dashes" tells the user what to do.
The Viewer Compatibility Problem and How to Work Around It
PDF JavaScript is supported in Adobe Acrobat Reader, Acrobat Pro, and most desktop PDF applications. It is not supported in most browser-based PDF viewers, including Chrome's built-in viewer, Firefox's PDF.js, and Safari's preview. It is partially supported in some mobile PDF apps and completely absent in others. If your form relies on conditional logic and validation scripts, and your recipient opens it in a viewer that does not execute JavaScript, they will see all fields, including the ones meant to be hidden, and none of the validation rules will fire.
There is no perfect technical solution to this. The best approach is a combination of clear labeling and a prominent instruction at the top of the form. Label conditional sections with their trigger condition: "If you selected Business above, complete this section." This way, even if the scripting fails, the user can follow the form manually. The Interactive PDF experience degrades gracefully into a usable static form rather than becoming incomprehensible.
Testing Conditional Forms Across Multiple Viewers
Before distributing a conditional PDF form, test it in at least four environments: Adobe Acrobat Reader on desktop, the Chrome built-in PDF viewer, the Safari or Preview PDF viewer on Mac, and a mobile PDF viewer on both iPhone and Android. In each environment, work through the form systematically. Change dropdown selections and verify the correct fields appear and disappear. Enter invalid data and confirm the validation messages appear and prevent submission. Save the form and reopen it to check that the saved state is consistent.
For forms going to a known audience, such as internal company forms or forms submitted through a specific portal, test only the viewers your audience actually uses. If everyone in your organization uses Adobe Acrobat, browser compatibility is irrelevant. If your form will be posted on a public website and opened by anyone with any device, assume that a significant percentage of users will see the form without JavaScript. Design the form to function acceptably in that degraded state, with all fields visible and all instructions clear, and let the conditional logic be an enhancement rather than a requirement.
When Conditional Logic Belongs in a Web Form Instead
If your form needs multi-step wizards, dynamic field creation, real-time server validation, or page reflow when fields appear and disappear, a web form is the right tool, not a PDF. PDF forms are static documents with interactive enhancements. Web forms are interactive applications with a document-like output. The distinction matters because building a complex conditional form in PDF, only to discover that half your audience cannot use it as intended, is a frustrating and time-consuming mistake.
A practical hybrid approach is to use a web form for data collection and conditional logic, and generate a PDF from the submitted data for signatures, archiving, and sharing. WukongPDF's PDF Editor works well in this workflow: collect the data via a web form, populate a PDF template with the responses, and deliver the polished PDF to the user for their records. The web form handles the logic. The PDF handles the presentation. Each tool does what it does best.