A PDF that stops being accessible after a certain date serves a specific purpose: sharing time-sensitive information that should not be readable indefinitely. Setting a PDF to expire requires either document-level scripting that checks the current date, or DRM-based protection that enforces access rules through a license server. Both approaches have limitations, and neither is absolute protection against a determined recipient who wants to retain access. But for routine business scenarios, Protect PDF expiry provides a practical deterrent against outdated documents circulating beyond their intended lifespan.
Key Takeaways
PDF expiry can be implemented through JavaScript that checks the system date when the document opens, or through a DRM server that validates access rights before displaying content. JavaScript-based expiry relies on the recipient's PDF reader having JavaScript enabled and the system clock being accurate. DRM-based expiry is more reliable but requires the document to check in with a license server each time it is opened. Neither method can prevent a recipient from taking screenshots or printing the document before it expires.
JavaScript-Based PDF Expiry
Test the expiry script in multiple PDF readers before distributing the document. Adobe Acrobat and Foxit Reader support JavaScript-based document actions differently, and a script that works in one may not work in the other. The most reliable cross-reader approach is a simple date comparison that displays an alert dialog. More complex scripts that attempt to close the document or blank its content are less portable across readers.
When embedding an expiry script, also add a fallback message that displays a warning even if the script cannot close the document. A script that attempts to call doc.close() may fail in some readers, but a script that displays an alert dialog with the text 'This document expired on [date]. Please contact [sender] for an updated version' will work in any reader that supports JavaScript. The alert does not prevent access, but it communicates the expiry clearly to the recipient.
PDF documents can contain JavaScript code that runs when the document opens. An expiry script checks the current system date against a hardcoded expiration date. If the current date is after the expiry date, the script displays a message and either closes the document or blanks the page content. The script is embedded in the PDF during creation and requires no server infrastructure. Any PDF tool that can add document-level JavaScript can implement this type of expiry.
The limitations are significant. JavaScript execution can be disabled in the PDF reader's preferences, which disables the expiry check. The system clock can be set back to a date before expiry, which defeats the date comparison. The script can be removed from the PDF by anyone with a PDF editor and basic knowledge of JavaScript. For these reasons, JavaScript-based expiry is a practical deterrent suitable for internal documents, drafts, and materials shared with cooperative recipients, but it is not a PDF Security measure that can resist deliberate circumvention.
DRM-Based PDF Expiry
When evaluating DRM platforms for document expiry, ask whether the platform supports offline access. Some DRM systems allow a document to be opened without contacting the license server for a specified period after the last online check. This is important for recipients who travel or work in environments with unreliable internet. An expiry policy that locks out users who cannot connect to the license server creates support requests and frustration. A grace period of 24 to 72 hours after the last successful license check balances security with usability.
For highly time-sensitive documents where even a 24-hour grace period is too long, configure the DRM platform to require an online check every time the document is opened. This ensures the document cannot be accessed even one minute past its expiry, but it also means the document is inaccessible without an internet connection. Reserve this strict setting for the most sensitive documents where availability is secondary to security.
Digital Rights Management systems add server-side enforcement to document expiry. The PDF is encrypted, and the decryption key is provided by a license server only when the document is opened. The license server checks the current date and the user's access rights before issuing the key. When the expiry date passes, the license server stops issuing keys, and the document cannot be opened. DRM-based expiry is resistant to clock changes and script removal because the expiry logic is on the server, not in the document.
The tradeoffs are cost and complexity. DRM systems require license server infrastructure, user authentication, and ongoing management. They are used primarily by publishers, educational institutions, and enterprises that need to control access to high-value or regulated content. For most business documents shared between colleagues or with clients, the cost and complexity of DRM outweigh the benefit. WukongPDF's document protection tools support both JavaScript-based expiry for simple use cases and integration with third-party DRM platforms for enterprise deployments.
Practical Alternatives to Document Expiry
For enterprise environments, consider a document management system that controls access at the server level rather than embedding expiry logic in individual PDFs. The DMS authenticates the user, checks the document's access policy, and either serves the PDF or denies access. This approach separates access control from document format and works with any PDF reader. The document itself has no expiry mechanism and relies entirely on the DMS for access enforcement.
For time-limited document sharing where technical enforcement is unnecessary, a simple cover page stating the document's validity period often suffices. Add a cover page with text like 'This document is valid for use until March 15, 2026. After that date, request an updated version from the sender.' The cover page approach requires no scripting, no DRM, and works in every PDF reader. It relies on the recipient's cooperation rather than technical enforcement, which is appropriate for most routine business document sharing.
For many scenarios, alternatives to document expiry achieve the same goal with less complexity. Sharing a document through a secure file sharing link that expires after a set time controls access without modifying the PDF. The recipient accesses the document through the link, which stops working after the expiry date. The PDF file itself has no expiry mechanism, but the means of accessing it does. This approach is simpler to implement and does not depend on the recipient's PDF reader configuration.
Watermarking the document with a notice such as "Valid only until March 2026" or "Superseded by version 2.0 after June 2026" communicates the expiry to human readers without relying on technical enforcement. A visible expiry notice puts the recipient on notice that the document should not be relied upon after the stated date. Combined with a policy of sending updated versions to all recipients before the stated date, watermarking covers many routine business scenarios without any technical complexity.
Frequently Asked Questions
What happens if the recipient changes their system clock to bypass the expiry check? For JavaScript-based expiry, changing the system clock to a date before the expiry deadline defeats the date comparison. There is no way to prevent this with client-side scripting alone. If clock-based bypass is a concern, the expiry mechanism should be server-side, such as DRM or a secure document portal. JavaScript-based expiry is appropriate only when the recipient is cooperative and the expiry serves as a reminder rather than a security enforcement mechanism.
Can I combine document expiry with other PDF security features like password protection? Yes. Password protection and document expiry operate independently. A PDF can require a password to open and also contain an expiry script that displays a warning after a certain date. The two features do not interfere with each other. Apply the password protection first, then add the expiry script. Test both features work together before distributing the document.
Can I make a PDF expire after a certain number of views rather than a date? Not with standard PDF features. View counting requires the document to track its own open count and store that count somewhere persistent, which standard PDF scripting does not support. DRM platforms can implement view-limited access because the view count is tracked on the server, not in the document.
Can an expired PDF be recovered or reopened?
For JavaScript-based expiry, yes. Disabling JavaScript in the PDF reader prevents the expiry script from running, and the document opens normally. For DRM-based expiry, recovery depends on the DRM system. Most DRM systems cannot be bypassed without the license server's cooperation, which makes expired DRM-protected documents effectively unrecoverable without authorization from the document owner.
Do all PDF readers support document expiry scripts?
No. Mobile PDF readers, browser-based readers, and some lightweight desktop readers do not support JavaScript execution. A PDF with a JavaScript expiry script will open without any expiry check in these readers. If your recipients use a variety of PDF readers, assume that JavaScript-based expiry will not work for a portion of your audience.
Is setting a PDF to expire different from setting a self-destruct timer?
Yes. Expiry prevents the document from being opened or makes its content unreadable after a date. A self-destruct feature, where the document deletes itself or permanently corrupts its own content after being opened, is not supported by the PDF specification and would require custom software beyond standard PDF tools. The terms are sometimes used interchangeably in marketing materials, but they describe different capabilities.