Stop Calling It 'Protected PDF.' Here's What's Actually Possible in the Browser.
You can't prevent a logged-in student from saving a PDF they're allowed to view. What you can do is raise the cost of casual copying enough that it stops happening — and stop selling clients on protection you can't deliver.
What 'protected' actually means
If a student can open a PDF in their browser, they can save it. They can use the browser's built-in PDF viewer download button. They can right-click. They can View Source on a custom viewer and grab the URL. They can take screenshots. They can print-to-PDF. Pretending otherwise is what gets vendors sued when a real piracy event happens and the client realizes the 'DRM' was right-click-disable JavaScript. The honest framing is: PDF security in a browser is friction, not prevention.
What S3 + aws:Referer actually does
A bucket policy that requires `aws:Referer: "https://yoursite.com/*"` will block someone pasting a direct S3 URL into a browser tab and downloading. It will not block someone who saves the file out of an authenticated session, and it will not block `curl -H 'Referer: https://yoursite.com/' <s3-url>`. We use this layer in production for one of our music education clients — it cuts off the most common abuse vector (sharing a CDN link in a Facebook group) and that was enough for the client to accept the tradeoff.
The native PDF viewer download button problem
Every browser ships a PDF viewer with a download button you cannot remove. There is no JavaScript flag, no HTML attribute, no Content-Disposition trick that hides it from a determined user. If your spec is 'no download button visible,' the only way to deliver is to render PDFs through a custom viewer like PDF.js — which means re-implementing zoom, search, page navigation, and accessibility from scratch, and accepting that the user can still hit Ctrl+S on the page itself.
PDF.js as the realistic ceiling
PDF.js is what every browser already uses under the hood (it's what ships with Firefox; Chrome's viewer is similar). Bundling it in your WordPress plugin gives you a viewer you can style and strip controls from. Important: render with the text layer enabled — canvas-only is a screen-reader dead zone, and serving educational PDFs to students with accessibility needs through a canvas-only viewer is asking for an ADA complaint. The text-layer version is roughly twice the file size and adds copy-paste-able text overlay, but that's the trade you're making for accessibility compliance.
Watermarking is the highest-ROI move
If your real concern is 'someone is sharing my PDFs and I want to know who,' watermark them with the logged-in user's email at render time. Server-side overlay is more reliable than client-side (a client-side overlay can be removed with DOM inspection). Watermarking does nothing to prevent sharing, but it converts a sharing event into a deterrent — users hesitate to post a PDF with their own email stamped on every page. We've found it more effective than any technical lock at meaningfully reducing leak rates.
What we tell clients
We're explicit in scoping: 'We can prevent direct URL access, prevent hotlinking, watermark with user identity, and disable the browser's default download UI. We cannot prevent screenshot, print-to-PDF, or determined extraction. Anyone selling you DRM-for-PDFs in a WordPress LMS is either selling licensed DRM (Adobe ARES, FileOpen — expensive, runs server-side) or selling you JavaScript that an undergrad can bypass.' We've never lost a project by being honest about this. We've taken over several from vendors who weren't.