Can Websites Prevent Screenshots? Browser Limits Explained
Ordinary websites cannot reliably stop screenshots. Learn what browser scripts, enterprise policies, screen sharing, and DRM can and cannot control.
Short answer: an ordinary public website cannot reliably prevent a visitor from capturing what is rendered on a device they control. JavaScript can disable a context menu or react to some keyboard events, but it cannot control operating-system screenshot tools, another application, a camera, or every browser capture path.
There are narrower controls. An organization can apply screenshot restrictions to managed browsers and devices, and DRM can obscure protected video on some supported configurations. Those controls depend on the administrator, browser, operating system, license, device, and content type. They are not a universal “uncapturable webpage” switch.
What a website can and cannot control
| Capture path | Can page JavaScript reliably block it? | What actually applies |
|---|---|---|
| Right-click menu | No | A script can suppress the menu event, but users can use other input paths. |
| Print Screen, system screenshot tools, or another app | No | These operate outside the page. |
| Browser extensions and browser capture features | No | Availability depends on browser policy and extension permissions. |
| A camera pointed at the display | No | Software controls on the device cannot stop an external camera. |
| Screen sharing requested by a web app | Partly | The Screen Capture API is permission-gated and user-selected; it is different from stopping screenshots. |
| Protected streaming video | Sometimes | DRM may obscure video in supported browser/device combinations. |
Why common website tricks do not prevent screenshots
Disabling right-click
<script>
document.addEventListener('contextmenu', event => event.preventDefault());
</script>
This only handles one browser event. It does not affect operating-system shortcuts, browser menus, accessibility tools, developer tools, extensions, or a second device. It can also make your site harder to use for legitimate keyboard and assistive-technology users.
Blocking keyboard shortcuts
<script>
document.addEventListener('keydown', event => {
const key = event.key.toLowerCase();
if (event.key === 'PrintScreen' || (event.ctrlKey && event.shiftKey && key === 's')) {
event.preventDefault();
}
});
</script>
A page only receives keyboard events while it has focus, and browsers or operating systems may consume shortcuts before the page sees them. Blocking a known shortcut is therefore an inconvenience, not capture prevention.
Clearing the clipboard or hiding content on blur
These approaches can disrupt copy and tab switching, but they do not remove pixels already displayed. A screenshot can be taken before the blur handler runs, by another process, or with a camera.
Detecting screenshots
Do not promise universal screenshot detection. The sources for this guide describe browser capture controls and screen-sharing APIs, but they do not establish a browser API that tells every website when the operating system has taken a screenshot.
Screen Capture API is for sharing, not blocking screenshots
The Screen Capture API lets a web application ask a user to select a display, window, or tab and provide a media stream for sharing. The user chooses what to share, and permission is required. Permissions Policy can control whether a document may use the feature, but it does not give a site control over operating-system screenshot shortcuts.
async function shareScreen() {
const stream = await navigator.mediaDevices.getDisplayMedia({ video: true });
const video = document.querySelector('video');
video.srcObject = stream;
await video.play();
}
Recent user interaction and permission are required for powerful capture features. The W3C Screen Capture working draft also explains that constraints do not let a requesting site narrow the choices shown to the user. Screen sharing and a screenshot taken with an OS tool are separate operations.
Managed browser policies: the practical enterprise exception
If an organization manages the browser and device, administrators can apply supported policies. These controls should be evaluated against the exact operating systems, browser versions, enrollment model, and licensing requirements.
Microsoft Edge
Microsoft’s Disable screenshots policy blocks screenshots made with keyboard shortcuts or extension APIs. Microsoft also documents remaining paths: “Even if you disable screenshots using this policy, users might still be able to take screenshots using Web Capture within the browser or other methods outside of the browser.” Treat this as a managed control over specified paths, not proof that a page is uncapturable.
Chrome Enterprise
Google documents screenshot prevention for managed users and browsers with a Chrome Enterprise Premium license. The help page distinguishes screenshot prevention from screen-share prevention and lists platform limits: screenshot prevention is available on Windows and Mac; screen-share prevention is supported on Windows; the setting is unavailable on Linux. The broader policy documentation also describes mobile and ChromeOS coverage. Confirm current eligibility, enrollment, and licensing with your administrator before promising protection.
Deployment checklist
- Identify whether the browser profile and device are organization-managed.
- Confirm the required Chrome Enterprise Premium license or Edge policy support.
- List every target OS, browser channel, and device type.
- Test keyboard shortcuts, browser capture features, extensions, screen sharing, print paths, and external cameras.
- Document what remains possible and communicate the limitation to users.
DRM can protect some video, not a general webpage
DRM systems can make protected video appear black or otherwise unavailable to some capture paths on supported browser and device combinations. Gumlet’s implementation guidance describes support differences across desktop and mobile environments. Verify the exact content-protection system and browser/device requirements with your video provider.
Do not generalize DRM behavior to ordinary images, text, documents, or arbitrary HTML. DRM is a narrow video-delivery mechanism, and unsupported combinations may still permit capture.
What to do when you publish sensitive content
- Reduce exposure: show only the data needed for the task and avoid placing secrets in client-rendered HTML.
- Control access: require authentication, authorize each resource, expire sessions, and revoke access when appropriate.
- Use watermarks for traceability: add a user or transaction identifier when leakage attribution matters. A watermark can deter or identify sharing; it does not prevent a screenshot.
- Use managed policies for managed users: evaluate Chrome or Edge controls when you control the workforce devices.
- Use DRM for licensed video: choose a provider whose supported matrix matches your audience.
- Set expectations: tell users that anything visible on a device may be photographed.
How to test your actual protection
- Test an unmanaged personal device as an ordinary visitor.
- Try OS screenshot shortcuts and built-in capture utilities.
- Try browser capture features, extensions, print-to-PDF, and developer tools.
- Try screen sharing through
getDisplayMedia()and record which permissions appear. - Repeat on every managed OS/browser combination if enterprise policies are involved.
- For DRM video, test supported and unsupported devices and browsers, including mobile.
- Record the result as “blocked path” or “available path”; never summarize it as simply “screenshots disabled.”
Troubleshooting
| Symptom | Likely cause | Fix or next check |
|---|---|---|
| Right-click is disabled but screenshots still work | The script only suppresses the context-menu event. | Remove the false assumption; use access controls and watermarking for risk reduction. |
| A shortcut blocker works in one browser only | Keyboard events and reserved shortcuts differ by browser and OS. | Test the OS capture tools separately; do not rely on page JavaScript. |
| Screen sharing still shows the page | Screen sharing is a user-approved display stream, not screenshot prevention. | Configure supported managed screen-share policies where applicable. |
| Chrome policy has no effect on Linux | Google documents the screenshot setting as unavailable on Linux. | Confirm platform coverage and use a supported managed environment. |
| Edge users can still capture through Web Capture | Microsoft documents Web Capture and other outside-browser paths as remaining possibilities. | Test and document those paths; combine policy with data minimization. |
| DRM video is black on one device but visible on another | DRM capture prevention varies by browser, OS, and device. | Check the provider’s support matrix and test the exact playback configuration. |
| You need to know whether a screenshot occurred | There is no universal browser signal established by the reviewed sources. | Use audit logs for access and watermarks for attribution instead of claiming detection. |
Performance, reliability, and cost considerations
Client-side blocking scripts add event handlers and user friction while offering limited protection. Enterprise policies add administration, licensing, enrollment, and cross-platform testing work. DRM adds encoding, license, and compatibility requirements. Access controls and minimizing rendered data usually provide more dependable risk reduction for ordinary web applications.
Budget for recurring verification: browser updates, operating-system changes, policy changes, and new capture tools can alter the paths your controls cover. Keep a documented test matrix and retest after major browser or DRM-provider releases.
Or skip the browser setup
If your goal is to capture websites for QA, documentation, reports, or an AI workflow, ScreenshotNeo provides a website screenshot API and MCP server. It is useful when you need a clean rendering rather than a way to stop other people from capturing your page.
One GET request returns PNG, JPEG, WebP, or PDF. Before capture, ScreenshotNeo can accept cookie or consent banners and remove more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and whether the request was billed.
cURL
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
Python
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)
Node.js
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 failed: ${res.status}`);
const buffer = Buffer.from(await res.arrayBuffer());
require('node:fs').writeFileSync('shot.webp', buffer);
See the ScreenshotNeo documentation for request options. Relevant controls include full-page capture with lazy images loaded, CSS-selector element capture, dark mode, 12 device presets or any viewport, retina scale, PDF paper size/margins/landscape/page ranges, HTML/CSS to image, custom CSS and JavaScript, clicks, hidden selectors, selector/delay/network-idle waits, request blocking, custom headers/cookies/user agent/Authorization, timezone and geolocation, transparent backgrounds, resizing, chosen cache TTLs, signed links, async jobs with signed webhooks, bulk capture of up to 100 URLs per call, usage data, and an OpenAPI specification. Parameter names used by other screenshot APIs also work, which helps when switching.
An MCP server exposes take_screenshot, get_page_info, and capture_pdf to Claude, Cursor, and other MCP clients. Plans include 1,000 shots per month free with no card; paid plans start at $5 for 3,000 shots. Yearly billing gives two months free, and every feature is available on every plan.
Create a free ScreenshotNeo account and get 1,000 screenshots a month with no card.
FAQ
Can a website block screenshots on iPhone or Android?
A public page cannot reliably control the device’s system capture features. Device-managed policies may change the result for an organization, but coverage depends on the platform and policy.
Can JavaScript tell when someone presses Print Screen?
A page may observe some keyboard events, but that is not a reliable signal for every operating system capture path and does not establish that a screenshot was taken.
Does disabling screenshots also stop screen recording?
Not automatically. Screenshot prevention and screen-share or recording controls are separate features with different browser and platform support.
Can a watermark stop screenshots?
No. It can discourage redistribution or help identify the source of a copy.
Is DRM suitable for protecting a paid HTML article?
No. The cited DRM guidance concerns protected video. For HTML articles, use authentication, minimize sensitive data, and consider traceable watermarks.
Conclusion
For an ordinary public website, assume that visible content can be captured. Browser scripts target narrow interactions, managed policies cover specific environments, and DRM protects some video configurations. Build your security plan around access control, data minimization, and traceability, then test the exact browsers and devices your users have.


