Interactive PDFs With JavaScript

PDFs can run JavaScript. The feature has been in the spec for decades and powers everything from form validation to interactive scientific charts to malicious payloads. In 2026, with modern PDF readers and security models, interactive JavaScript-enabled PDFs still have a place, but a more constrained one. This guide covers what's possible, what's risky, and where the format makes sense today.

What PDF JavaScript can do

PDF JavaScript (sometimes called "JavaScript for Acrobat" or PDF JS, not to be confused with Mozilla's pdf.js renderer) provides:

Form field validation: check that a field matches a regex, isn't empty, falls within a range.
Calculations: total a column of form values; date math.
Conditional logic: show/hide fields based on input.
Document actions: code that runs on open, on close, on page change.
User-triggered actions: button click runs code.
Communication: in some viewers, talk to a server.
Multimedia: trigger embedded video, audio (limited support in 2026).

It's a real scripting environment, with access to many PDF objects.

Where you see it

JavaScript-enabled PDFs are common in:

Government forms: IRS forms, tax-software-exported returns.
Insurance and benefits forms: long forms with calculations.
Interactive scientific publications: some journals embed interactive figures.
PDF-based applications: rare but exists (kiosk-style apps).
Phishing and malware: alas, also.

The JavaScript runtime

The API isn't browser JavaScript. It's a custom Adobe-defined API:

app: the viewer application.
doc or this: the current document.
Form fields: getField("name") returns a field object with .value, .fillColor, etc.
Events: each script runs in an event context (event.target, event.value).

Some examples:

// Validate a field value
if (event.value < 0 || event.value > 100) {
  app.alert("Value must be between 0 and 100");
  event.rc = false;
}

// Sum two fields into a third
this.getField("Total").value =
  Number(this.getField("Subtotal").value) +
  Number(this.getField("Tax").value);

// Show or hide a field based on a checkbox
this.getField("AdditionalInfo").display =
  this.getField("HasMore").value === "Yes" ? display.visible : display.hidden;

Where it runs

Different viewers support JavaScript differently:

Adobe Acrobat / Reader: full support; the reference implementation.
Foxit Reader, PDF-XChange Editor: substantial support.
Apple Preview: very limited.
Browser-embedded viewers: most disable JavaScript by default (security).
Mobile PDF apps: typically disabled.
Mozilla pdf.js (Firefox built-in): limited or disabled.

Don't assume JavaScript will run everywhere. If your PDF depends on it, test in the viewers your audience uses.

Form-field validation patterns

The most common legitimate use:

Required field:

if (event.value === "") {
  app.alert("This field is required.");
  event.rc = false;
}

Numeric range:

var v = Number(event.value);
if (isNaN(v) || v < 0 || v > 1000) {
  app.alert("Enter a number between 0 and 1000.");
  event.rc = false;
}

Date format:

var pattern = /^\d{4}-\d{2}-\d{2}$/;
if (!pattern.test(event.value)) {
  app.alert("Date must be YYYY-MM-DD.");
  event.rc = false;
}

Conditional required:

var required = this.getField("OtherSelected").value === "Yes";
if (required && event.value === "") {
  app.alert("Please specify the 'Other' value.");
  event.rc = false;
}

For more on validation, see how to add validation to PDF form.

Calculations

Sum, total, tax, discount: classic.

Subtotal of line items:

var sum = 0;
for (var i = 1; i <= 10; i++) {
  var v = Number(this.getField("Line" + i).value || 0);
  sum += v;
}
event.value = sum;

Tax and total:

var subtotal = Number(this.getField("Subtotal").value);
this.getField("Tax").value = (subtotal * 0.08).toFixed(2);
this.getField("Total").value = (subtotal * 1.08).toFixed(2);

See how to add calculations to PDF form.

Document-level actions

Run on open, on save, on close:

// On open: jump to last viewed page
this.pageNum = this.numPages - 1;

// On save: warn if unsaved required fields
if (this.getField("Signature").value === "") {
  app.alert("Please sign before saving.");
}

In 2026, most readers prompt the user before running document-open scripts. Don't rely on them executing silently.

Security considerations

PDF JavaScript has been a vector for malware for years:

Buffer overflows in old viewers.
Drive-by execution triggered by document opening.
Phishing via fake form behaviors.
Exfiltration via network calls (mostly blocked now).

Modern viewers sandbox JavaScript heavily:

No filesystem access.
No arbitrary network requests (with some exceptions for form submission).
No eval() from untrusted sources.
User prompts for sensitive actions.

For users:

Disable PDF JavaScript in Acrobat if not needed (Preferences > JavaScript > Enable Acrobat JavaScript).
Keep readers updated.
Open suspicious PDFs in a sandbox (browser viewer, virtual machine).

For senders:

Don't assume the audience can run your JavaScript.
Provide fallbacks (a non-interactive form version).
Sign and certify forms for users to trust them.

Building interactive PDFs

Tools that author JavaScript-enabled PDFs:

Adobe Acrobat Pro: the canonical tool. Form Editor with JavaScript console.
Foxit PhantomPDF: similar.
Programmatic: libraries like iText (Java/.NET), pdf-lib (JavaScript), PDFBox (Java) let you embed JavaScript when generating PDFs.
LibreOffice: limited form features; can embed simple JavaScript.

For fillable form fundamentals, see making a PDF fillable and how to create fillable PDF form.

Distribution

When sending interactive PDFs:

Test in major viewers the audience uses.
Provide instructions for enabling JavaScript if disabled.
Sign the PDF so users can trust it. Signed PDFs are more likely to run JS without warnings.
Include an alternative (printable, non-interactive) version.

Limitations of PDF JS

Things PDF JavaScript can't do well:

Complex DOM manipulation: PDFs don't have a DOM in the HTML sense.
Modern web APIs: no Fetch, no WebSocket, no IndexedDB.
Advanced UI: it's still a PDF; you can't build a SPA.
Cross-platform consistency: viewer differences cause headaches.

For complex interactive applications, an HTML page is dramatically better. PDFs make sense when the document is the primary artifact (a form, a report) and interactivity is added value.

XFA (a sidebar)

A more powerful interactive PDF technology: XFA (XML Forms Architecture). XFA forms have richer dynamic behavior than acroforms with JavaScript. They are also more complex and have less viewer support in 2026.

Adobe deprecated XFA in PDF 2.0; new forms should be acroform with JavaScript, not XFA. See XFA forms explained for the deep dive.

Modern alternatives

For new projects:

Web forms (HTML + JavaScript) for any form that needs computation or complex interaction.
PDFs for archival: capture the form-state at submission as a static PDF.
Hybrid: HTML for interaction; generate a flattened PDF on submission.

This is the dominant 2026 pattern. Pure PDF-with-JavaScript forms are increasingly seen as legacy.

Debugging PDF JavaScript

Adobe Acrobat has a JavaScript Debugger:

Preferences > JavaScript > Enable JavaScript debugger.
Tools menu > JavaScript > Debugger.
Set breakpoints; inspect variables.

For programmatic generation, log to the JS console or surface errors via app.alert().

Common gotchas

Number-as-string. Form fields are strings. 1 + 1 becomes "11", not 2. Number(field.value) or +field.value to coerce.

Different decimal separators. European locales use commas; US uses periods. Validation regex must adapt or normalize.

Viewer differences. Acrobat behavior differs from Foxit; both differ from browser viewers. Test.

Script runs at unexpected times. "On Focus" vs "On Blur" vs "Validation" events all behave differently.

Cached field references. Scripts run in event scope; this may not be what you expect.

Self-modifying scripts. PDFs that change fields based on scripts can produce loops. Be careful with circular references.

Practical recipe

If you need interactive form behavior in a PDF:

Verify the audience can run JavaScript in their viewers.
Use Acrobat Pro or Foxit PhantomPDF to author.
Test validations with edge cases.
Sign and certify the document so users trust the JS.
Provide fallbacks for users who can't run JS.
Consider an HTML alternative for genuinely complex interaction.

For browser-based PDF tasks that don't require JavaScript (filling out, signing, flattening), Docento.app handles them locally.

Takeaway

PDF JavaScript is a real feature with real uses, mostly form validation and calculation. It is not a great choice for novel interactive applications in 2026; HTML covers that better. For PDFs where interactivity adds value (long forms, calculations), JavaScript still pays back. Test in the viewers your audience uses, sign the document, and provide fallbacks. See also making a PDF fillable, XFA forms explained, and PDF form field types explained.