BlogScreenshots on your device
Can Websites Detect Print Screen on macOS and Windows?
Usually no: websites can see some page keyboard events, but they cannot reliably know when macOS or Windows creates a local screenshot.
Usually, no. An ordinary website has no general browser API that reports every screenshot made with macOS or Windows system tools. JavaScript can observe keyboard events that reach the page, but that does not reliably reveal whether an operating-system screenshot shortcut, Snipping Tool action, or third-party utility created an image.
A website can receive a live display stream only when the user deliberately starts browser screen sharing and grants permission. The Screen Capture API is a user-selected, permission-gated sharing feature, not a passive notification that a local screenshot occurred.
What a website can and cannot know
| Situation | What the site may learn | What it cannot establish |
|---|---|---|
| The page is focused and receives a key event | A key was pressed; a script can inspect the event. | That a screenshot was created, saved, or copied, or that every screenshot shortcut reaches the page. MDN documents the scope of keydown events. |
| The user starts browser screen sharing | A user-selected display, window, or tab stream after permission. | That the user used Print Screen or a macOS screenshot shortcut. MDN’s getDisplayMedia documentation describes the prompt and selection flow. |
| An enterprise-managed browser or device | An administrator may restrict capture in supported configurations. | A universal notification to every ordinary website that a screenshot was attempted. |
| A local OS or third-party screenshot utility | Usually nothing is exposed to the page. | Exact behavior across all utilities, browsers, DRM systems, and device policies. |
How browser keyboard events work
JavaScript can register a keydown listener on the document or window. The event describes keyboard activity delivered into the browser context, including modifier keys and a key value. It is evidence that the page received an input event; it is not proof that an operating-system capture happened.
<!doctype html>
<meta charset="utf-8">
<title>Keyboard event logger</title>
<pre id="log">Focus this page, then press keys.</pre>
<script>
const log = document.querySelector('#log');
document.addEventListener('keydown', (event) => {
const details = {
key: event.key,
code: event.code,
meta: event.metaKey,
ctrl: event.ctrlKey,
alt: event.altKey,
shift: event.shiftKey,
timestamp: new Date().toISOString()
};
log.textContent = JSON.stringify(details, null, 2);
});
</script>
This logger may show a key combination when the browser sends it to the page. It may show nothing for a system-reserved shortcut, for a shortcut handled by another application, or when the page is not the active recipient of keyboard input. Do not label a key event as a confirmed screenshot.
Windows: Print Screen, Snipping Tool, and screen capture
Windows capture behavior depends on the keyboard, Windows version, browser focus, accessibility settings, enterprise policy, and any capture application installed. The Print Screen, Alt+Print Screen, Windows+Shift+S, and vendor-specific shortcuts may be handled by Windows or another process before the page sees a browser event.
A page can therefore implement a best-effort keyboard notice, but it cannot conclude that an image exists. The user might press a key and cancel the selection, copy pixels without saving a file, or use a hardware or third-party tool. Conversely, a screenshot can be taken while another window has focus and the page receives no event at all.
macOS: screenshot shortcuts and browser focus
macOS commonly uses Command+Shift+3 for a full display, Command+Shift+4 for a selected area, and Command+Shift+5 for the screenshot and recording controls. These are system-level workflows. A focused browser page might observe parts of a key sequence in some setups, but a page cannot rely on receiving every combination or infer that the capture completed.
Use event.metaKey when inspecting Command-modified events. Treat the result as an input hint only, and avoid collecting or transmitting raw keystrokes unless the user has a clear, informed reason to enable that diagnostic.
document.addEventListener('keydown', (event) => {
const macScreenshotHint = event.metaKey && event.shiftKey &&
['3', '4', '5'].includes(event.key);
if (macScreenshotHint) {
console.log('A possible macOS screenshot shortcut reached the page.');
}
});
Browser screen sharing is a different mechanism
The W3C Screen Capture API exposes navigator.mediaDevices.getDisplayMedia(). The browser must let the user choose a surface and obtain permission for that sharing session. The resulting stream can be rendered in a video element or sent through WebRTC, but it does not tell the site that the user pressed a local screenshot shortcut.
<button id="share">Share a display</button>
<video id="preview" autoplay muted playsinline></video>
<script>
document.querySelector('#share').addEventListener('click', async () => {
try {
const stream = await navigator.mediaDevices.getDisplayMedia({
video: true,
audio: false
});
document.querySelector('#preview').srcObject = stream;
stream.getVideoTracks()[0].addEventListener('ended', () => {
console.log('The user stopped sharing.');
});
} catch (error) {
console.error('Sharing was cancelled or unavailable:', error.name, error.message);
}
});
</script>
The user action, chooser, and permission are intentional parts of the API. A page cannot invoke this silently to monitor screenshots. See the W3C Screen Capture specification and MDN reference.
Managed browsers and specialized restrictions
Administrators can change capture behavior for managed users and browsers. Google documents Chrome Enterprise Premium screenshot prevention for supported Windows and Mac deployments. Microsoft documents Edge policies controlling which origins may use desktop, window, and tab capture, with Windows and macOS support listed for Edge 97 and later. These policies control or restrict capture in a managed environment; they do not create a universal screenshot event for an ordinary website.
Apple’s allowsScreenshots setting belongs to Automatic Assessment Configuration and concerns screenshots copied to the clipboard in that assessment context. It is a narrowly scoped platform control, not a general web notification.
- Google Chrome Enterprise Premium screenshot prevention
- Microsoft Edge ScreenCaptureAllowed policy
- Apple’s allowsScreenshots documentation
What not to claim in an application
- Do not claim that a
keydownevent proves a screenshot was saved. - Do not claim that no event proves no screenshot occurred.
- Do not describe
getDisplayMedia()as screenshot detection; it is active screen sharing. - Do not promise identical behavior across browsers, operating-system versions, keyboards, DRM playback, or enterprise policies.
- Do not use hidden event listeners to collect general keystrokes. If you log diagnostic input, explain what is collected and keep it local where possible.
Implementation checklist
- Decide whether you need a user-facing warning, an audit hint, or actual capture prevention. A page script can provide only a limited hint.
- Listen for
keydownonly while the relevant page or control has focus. - Record modifier state and browser/OS context only when necessary.
- Label the result as “possible shortcut detected,” never “screenshot confirmed.”
- Use
getDisplayMedia()only for a user-started sharing workflow with a clear explanation. - For managed devices, configure supported enterprise policies and document their scope separately from website code.
Troubleshooting
No key event appears when Print Screen is pressed
The operating system or another utility may consume the shortcut before the browser. The page may also be unfocused. Test with an ordinary key to verify the listener, then treat missing Print Screen events as expected behavior rather than a browser failure.
A key event appears but no screenshot exists
The event is only keyboard input. The user may have cancelled the capture, selected another window, or used the key for a different purpose. Keep the event as a hint.
getDisplayMedia() throws NotAllowedError
The user may have cancelled the chooser, denied permission, or the browser may require a transient user gesture. Call it directly from a visible button click and handle cancellation without retry loops.
getDisplayMedia() is unavailable
Check that the page is served in a secure context and that the browser supports the API. Provide an explanatory fallback; do not silently treat unavailability as evidence of a screenshot.
Enterprise testing differs from personal testing
Managed policies, browser versions, device configuration, and content-protection software can alter capture behavior. Record the policy and browser version when reproducing an issue.
Performance, reliability, and cost notes
A document-level keydown listener has negligible work when it only checks a few properties. Avoid sending every event to a server; debounce any diagnostic reporting and collect only the minimum data needed. Screen sharing is substantially heavier because it creates a live media stream and may consume CPU, memory, bandwidth, and battery.
There is no reliable client-side success signal for an arbitrary OS screenshot, so a “detected screenshot” metric will have false positives and false negatives. If your requirement is to produce consistent images of a page for testing, archives, or documentation, generate the image from a controlled capture workflow instead of trying to infer what a visitor did locally.
Or skip the browser setup
ScreenshotNeo provides a website screenshot API and MCP server. One request returns a PNG, JPEG, WebP, or PDF. Before capture it accepts consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the result with X-Page-Verdict and X-Billed headers.
See the ScreenshotNeo documentation for all options, including full-page and element capture, device presets, dark mode, retina scale, custom CSS and JavaScript, waits, request blocking, cookies and headers, geolocation, caching, signed links, asynchronous jobs, bulk capture, and the usage API.
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 fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));
An MCP server lets Claude, Cursor, and other MCP clients call take_screenshot, get_page_info, and capture_pdf. The Free plan includes 1,000 shots each month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.
FAQ
Can a website see that I pressed Print Screen?
It may see a keyboard event if the browser delivers it to the focused page, but it cannot reliably know that a screenshot was created.
Can websites detect Command-Shift-3, -4, or -5 on Mac?
Not reliably. Those are macOS screenshot workflows, and the page may not receive their key events.
Does browser screen sharing reveal local screenshots?
No. getDisplayMedia() starts a separate, permissioned sharing session chosen by the user.
Can a company block screenshots?
Supported enterprise policies and specialized assessment or content-protection configurations can restrict capture, but their scope depends on the product and configuration.
Can I guarantee that a visitor did not take a screenshot?
No. A normal website cannot establish that from missing keyboard events or other page signals.


