How to Prevent Print Screen on a Website and Protect Captured Content

Short answer: You cannot reliably prevent a visitor from taking a screenshot of content visible on their device. A website can discourage casual copying, limit what content a user can access, and control whether its own code may request a browser screen-capture stream. Those controls do not disable operating-system screenshot commands, browser extensions, third-party capture tools, or a camera pointed at the screen.

The practical goal is to reduce unnecessary exposure, make bulk extraction harder, and add traceability if content is redistributed. Treat every screen-visible item as something an authorized viewer could preserve.

1. What a website can and cannot control

A page can receive some keyboard and pointer events, but it cannot enforce rules over the visitor’s device. Blocking a key combination may deter a basic attempt; it does not stop native screenshot tools or capture software that does not use the page’s event handlers.

The browser’s Screen Capture API is a separate feature: a web application can call getDisplayMedia() to ask the user to select a screen or portion of one and receive a MediaStream, commonly for screen sharing or recording. Browser permission and selection safeguards apply. This API gives a site a way to request capture; it is not a switch for enabling or disabling the visitor’s own screenshot commands. MDN: Screen Capture API and MDN: getDisplayMedia().

The Clipboard API handles clipboard operations such as reading or writing copied data. It does not control screenshots. Disabling selection or copy events therefore does not protect visible pixels. MDN: Clipboard API.

2. Restrict your own use of the Screen Capture API

If your application should not initiate browser screen sharing or recording, a Permissions Policy can deny its use of getDisplayMedia(). This is useful for controlling that browser capability. It does not prevent Print Screen or another independent capture tool.

For a document you control, the HTTP response can include:

Permissions-Policy: display-capture=()

The empty allowlist disallows the feature for the document. If the page calls navigator.mediaDevices.getDisplayMedia() while the policy blocks it, the call rejects with NotAllowedError. See MDN: display-capture directive.

For an iframe, the top-level document can also restrict the feature through its Permissions Policy and iframe permissions. Check the policy sent by the server and the iframe’s configuration together. Do not add an allow rule for a feature the embedded application does not need.

When a site does need screen sharing

If your application intentionally shares a tab or presents content through getDisplayMedia(), consider the Element Capture and Region Capture APIs to limit the area included in that authorized stream. These APIs shape a browser capture stream; they do not restrict screenshots taken independently by the user. Review Element Capture and Region Capture and MDN: RestrictionTarget for their API details and availability.

3. Use controls that address the real risk

Control	Can help with	Does not do
Keyboard or copy-event interception	Discouraging a few ordinary page-level copy actions	Preventing OS screenshots, external tools, or capture of visible pixels
display-capture policy	Blocking the document’s use of getDisplayMedia()	Blocking native screenshot tools
Element or Region Capture	Limiting an authorized browser capture stream to an element or region	Stopping independent screen capture
Authentication, authorization, and rate limits	Reducing unauthorized access and bulk extraction	Stopping a permitted viewer from preserving visible content
User-specific watermark	Discouraging casual redistribution and helping attribute a leak	Making displayed content impossible to capture

Protect content at the server

• Authenticate and authorize each content request. Do not rely on hidden buttons or client-side checks to protect an asset.
• Return only the data each user needs. If a page loads the full document or original image, hiding part of it with CSS does not keep that data secret from the client.
• Use sensible rate limits, download controls where useful, access logs, and anomaly monitoring to make automated collection harder to scale.
• Plan for redistribution with clear terms, a reporting path, and an enforcement process appropriate to your content.

Consider visible, user-specific watermarks

A visible mark tied to a user or session can discourage casual sharing and help identify the source of a leaked image. Choose a placement that remains legible without obscuring the content users need. Invisible or forensic watermarking depends on the asset type and implementation; verify a provider’s claims independently before relying on it. No watermark makes capture impossible.

Use interaction blocking sparingly

Disabling right-click, keyboard shortcuts, text selection, or clipboard actions can interfere with accessibility tools and normal work while leaving screenshots available. If you use these measures for a narrow deterrence purpose, explain the behavior, preserve essential keyboard and assistive-technology workflows, and test with the accessibility needs of your audience in mind.

4. A limited deterrent for ordinary copy shortcuts

The following example blocks common copy shortcuts and the context menu inside a marked element. It is intentionally a deterrent only. It does not block a screenshot, and it can make content harder to use with assistive technology. Do not apply it to an entire site without a specific reason.

<article class="copy-deterrent">
  <p>Example content. A visitor can still capture this page.</p>
</article>

<script>
  const protectedArea = document.querySelector('.copy-deterrent');

  protectedArea.addEventListener('contextmenu', (event) => {
    event.preventDefault();
  });

  protectedArea.addEventListener('copy', (event) => {
    event.preventDefault();
  });

  protectedArea.addEventListener('keydown', (event) => {
    const key = event.key.toLowerCase();
    const isCopyShortcut = (event.ctrlKey || event.metaKey) && key === 'c';
    if (isCopyShortcut) event.preventDefault();
  });
</script>

This affects only events handled by this page in this element. A visitor can use other software, browser tools, device features, or a camera. The code also does not provide meaningful confidentiality: the page has already delivered its rendered content to the visitor.

5. Check the behavior and troubleshoot

Symptom	Likely cause	What to do
A visitor can still take a screenshot after shortcut blocking	The website cannot control native or independent capture tools.	Use access controls, minimize delivered data, watermarks, and monitoring to reduce exposure or improve traceability.
getDisplayMedia() rejects with NotAllowedError	The user denied the prompt, the browser disallowed the request, or a Permissions Policy blocks it.	Check the browser permission flow, secure-context requirements, response policy, and iframe configuration. If capture should be denied, this can be the expected result.
Copy blocking does not affect all content	The handler is attached to one element, but the event occurs elsewhere or another interaction path is used.	Check the event target and scope. Keep in mind that broader blocking still cannot prevent screenshots and may harm accessibility.
An embedded page can request capture unexpectedly	The iframe or top-level policy permits the feature.	Review the top-level Permissions Policy and iframe permissions; remove unneeded grants.
Users report keyboard or screen-reader problems	Shortcut, selection, or context-menu blocking interferes with expected interaction.	Remove the restriction or narrow it, and test keyboard navigation and assistive-technology use.

6. Performance, reliability, and cost considerations

Permissions Policy is a browser capability restriction, not a content-protection service. It is lightweight, but it protects only the API it governs. Event handlers for copy or keyboard deterrence have little technical scope and add no meaningful assurance about screenshot prevention. Authentication, server-side authorization, rate limiting, logging, and watermark generation should be designed around the application’s content volume and user experience; there is no universal performance or cost figure for these measures.

For reliability, assume client-side controls can be bypassed or may behave differently across browsers and assistive technologies. Keep authorization decisions on the server, make policy headers part of deployment configuration, and monitor access patterns. This guidance describes browser API boundaries; it does not establish that any deterrent prevents capture or assess a particular anti-screenshot vendor.

7. Or skip the browser setup

If your job is to capture a page for QA, documentation, or monitoring, ScreenshotNeo is a website screenshot API and MCP server. It does not prevent visitors from taking screenshots; it gives developers a one-request way to capture a URL as an image or PDF. See the API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents use screenshot tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up free and get 1,000 screenshots a month with no card.

8. FAQ

Can I disable Print Screen with JavaScript?

No. JavaScript can intercept some page events, but it cannot reliably control operating-system screenshot commands or independent capture tools.

Does disabling right-click protect images?

No. It may discourage one interaction, but it does not stop screenshots or other ways of preserving content already delivered to a browser.

Does display-capture=() block screenshots?

No. It blocks the document’s use of getDisplayMedia() under that policy. It does not block native or unrelated capture software.

Can a watermark stop someone sharing a screenshot?

No. A user-specific watermark can discourage casual redistribution or help attribute a leak, but it cannot guarantee prevention.