A recipe on a kitchen counter, a boarding pass at a gate, or a long reading session can all be interrupted by the same ordinary setting: the screen goes dark. The Screen Wake Lock API offers websites a narrow way to ask the device to stay awake while a page is in use. It sounds small, but it is a useful example of how convenience and user control meet in a modern browser.
What the Screen Wake Lock API actually does
A site can request a screen wake lock through the browser. While that request remains active, the device may keep its display from dimming, turning off, or locking automatically. This is not a general command to keep every part of a computer running, and it does not give the site access to your files, camera, microphone, or screen contents. It affects the display’s sleep behavior for a visible page.
Consider a cooking guide that keeps the steps readable when your hands are occupied. A presentation controller or a page showing a scannable ticket has a similar reason to stay visible briefly. The benefit is real when the experience makes its purpose clear and ends the request when that purpose ends.
According to MDN’s Screen Wake Lock API guide, a page requests a lock with navigator.wakeLock.request("screen"). The browser returns a handle if it succeeds. A site can then release it, and the system can revoke it. That distinction matters: a successful request is not a permanent override of your device settings.
When a screen wake lock stops working
Wake locks belong to active, visible documents. If you switch tabs or the page becomes inactive, the browser releases the lock; a site that needs it again must request it when the page returns. A browser or operating system can also refuse or release a request for reasons such as low battery, power-saving settings, or policy. The Chrome developer guidance explicitly advises sites to handle failed requests and limit their impact on system resources.
This is why a page should not promise that its display will always stay on. It can ask, show whether the request is active, and provide an obvious way to stop. The device remains in charge. If you deliberately lock your computer, a website should not be understood as a way around that action.
Is this a privacy permission?
The API is primarily about usability and battery life, not reading personal data. It does not reveal your location or identify other tabs. Yet it still changes how your device behaves. A poorly designed page could keep the display lit longer than expected, which may drain battery or leave information visible to someone nearby. In a shared room, the practical privacy issue is the content left on the screen, not a hidden data feed to the site.
Browsers and site operators have controls here. The screen-wake-lock Permissions Policy can limit which embedded content may use the feature. By default, a third-party frame is not simply entitled to request it. The site’s own interface should also make the active state and its purpose understandable. A lock obtained silently for a long-lived page is poor design even if the API call itself is allowed.
This differs from a camera or microphone request. Those can collect new information from the world around you; wake lock keeps an already visible page visible. Treat them as different questions. If you are checking a site’s behavior, ask whether it has a good reason to keep the screen on and whether it stops once the task ends.
What to do if a page keeps your screen awake
First, close the tab or move away from the page and see whether normal display timeout returns. If you are using a kiosk, timer, presentation, or media app, look for its “keep screen on” setting and switch it off when finished. Your operating system’s sleep and lock settings are still worth checking. A screen that never locks may reflect an OS setting, a desktop app, a connected display, or a browser tab; do not assume a website is the cause without testing.
If battery life matters, favor apps that request wake lock only for a live activity and clearly say so. A timer for a single session is more considerate than a permanent request on every visit. And when stepping away from a shared computer, lock it yourself rather than relying on an inactivity timer. A wake lock is designed to postpone that timer.
Our guide to browser permissions explains how to judge more sensitive requests. For the related question of what happens when you leave a tab, see our Page Visibility API explainer. Neither feature should be mistaken for a site seeing everything you do elsewhere in the browser.
The useful boundary
The best browser features solve a concrete problem without taking broad control. Screen wake lock can prevent an inconvenient interruption, but it should remain temporary, visible, and easy to end. A site can request; the browser and device can say no. That balance is more useful than a simple “safe” or “unsafe” label, and it is the right question to bring to any feature that changes your device’s behavior.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.