Viewer protection
Soft deterrents that make casual copying harder without claiming to prevent determined access.
The viewer-protection settings are deterrents against casual copying, not DRM. Your browser necessarily receives the page content in order to display it, so anyone determined to capture it can do so—with a screenshot, a phone camera, or a print-to-PDF tool. What these controls do is raise friction for the uninvested reader.
Every one of them runs in the reader's browser, inside the EveryPage viewer. None of them changes the bytes that are served, and none survives leaving the viewer: a reader who requests the document's URL directly gets the PDF in their browser's own PDF viewer, where right-click, selection, printing and screenshotting all work normally. Watermarking is the one setting in the same panel that changes the served document itself, and even it marks a copy rather than preventing one.
How protection works
Protection lives in the editor's Protection panel, alongside the watermark setting. Three toggles cover viewer protection:
- Block Right-Click & Copying — one switch that sets both the context-menu and text-selection flags
- Block Printing
- Blur When Window Loses Focus
Each flag is stored on the server as part of the file's viewer settings and re-checked against the owner's plan when a viewer loads the document, so a downgrade takes effect for readers immediately.
Block right-click and copying
One toggle, two stored flags. Right-clicking the document produces no menu, and the document area is rendered with user-select: none, so a reader cannot triple-click to select, drag to highlight, or Shift+click. They can still copy via keyboard shortcuts where the browser allows it, read the rendered text, screenshot it, use developer tools to inspect the underlying DOM, or open the PDF outside the viewer. This deters the path-of-least-resistance copier and stops no one motivated.
Tier: Basic and above.
Block printing
When enabled, the viewer intercepts the print and save shortcuts (Ctrl+P / Cmd+P and Ctrl+S / Cmd+S) and suppresses the keyboard action, and a @media print rule hides the document from print output, so menu-driven printing and print-to-PDF produce a blank page rather than the document.
Both halves are viewer-side CSS and JavaScript. A reader who disables JavaScript or CSS, opens the PDF outside the viewer, or screenshots the pages and prints those is unaffected. Print blocking prevents the accidental "oops I printed it" moment, not the intentional one.
Tier: Basic and above.
Blur when the window loses focus
When enabled, the pages blur (a 14px CSS blur) behind a dimmed veil whenever a reader switches to another tab, minimizes the window, or the window loses keyboard focus. It clears on return. This deters screen-sharing and over-the-shoulder exposure while a reader is away from the document, but it does not prevent capture. A reader can screenshot while the tab is active, use a screen recorder, or photograph the monitor.
Tier: Pro. If the owner's plan drops below Pro, this flag stops being sent to viewers.
Summary table
| Control | Effect | Tier |
|---|---|---|
| Block right-click & copying | Suppresses the context menu and text selection in the viewer; does not prevent keyboard copy, DOM inspection, or reading the PDF outside the viewer. | Basic+ |
| Block printing | Blocks print/save shortcuts and blanks the document in print output; does not prevent printing a screenshot or the file opened elsewhere. | Basic+ |
| Blur on focus loss | Blurs the view when the window or tab loses focus; does not prevent screenshots or recording while the tab is active. | Pro |
When these work and when they don't
Protection works best when your readers are:
- Browsing casually and don't want to be bothered with workarounds
- Viewing on a trusted device in a secure context (an office, a closed meeting)
- Relying on the viewer interface, not the underlying bytes
Protection does not work if your reader is:
- Taking a screenshot or screen recording
- Using developer tools to inspect the page
- Requesting the document's URL directly instead of using the viewer
- Motivated to circumvent friction
Best practice: combine with watermarking
To leave a trace on a leaked copy, enable watermarking as well as, or instead of, these toggles. The watermark is stamped into the served PDF, so a forwarded copy carries an identity line and a timestamp. How useful that identity is depends on what the reader gave you: an invited or gate-captured email address names a person, while an anonymous reader gets only an opaque per-session key. Watermarking marks a copy; protection only adds friction to casual copying. Neither prevents a leak.
Related: