The Screen Wake Lock API explained

For most of the web's history, a page had no honest way to ask the device to keep the screen on. Video sites used tricks, recipe sites told people to change their phone settings, and dashboards relied on browser extensions. The Screen Wake Lock API replaced those tricks with a single, standardised request that the browser can grant, deny, or revoke on behalf of the user.

What the API actually does

A page asks for a lock by calling navigator.wakeLock.request('screen'). If the browser agrees, it returns a sentinel object. While that sentinel is active, the operating system is told not to dim the display or put the device to sleep because of inactivity. When the page is finished, it calls sentinel.release() and normal power management resumes.

The only lock type defined today is 'screen'. It keeps the display awake, which is exactly what you want for reading, cooking, presenting, or watching a dashboard. It does not simulate keyboard or mouse input, which is why it cannot stop a chat app from marking you as away: that status is decided by the chat app, not by the display.

Requirements and limits

• Secure context. The API only exists on pages served over HTTPS (and on localhost for development).
• A visible page. Requests made from a hidden tab are rejected, and an active lock is released automatically when the tab becomes hidden. This is a deliberate privacy and battery protection.
• User agent discretion. A browser may refuse a request, for example when the battery is critically low or when a battery saver mode is on. Code must handle the rejected promise instead of assuming success.
• One lock per request. Each call returns its own sentinel, so a well-behaved page keeps a reference and releases it when it is done.

Browser support

Chromium-based browsers (Chrome, Edge, Opera, Samsung Internet) have supported the API since version 84. Safari added it in version 16.4, including on iPhone and iPad. Firefox added support more recently, so current releases handle it, while older versions do not. Because support varies with the exact version and platform, it is sensible to feature-detect with 'wakeLock' in navigator rather than checking browser names.

Why a lock disappears and how to handle it

The most common surprise is that the lock vanishes when you switch tabs or minimise the window. The browser fires a release event on the sentinel at that moment. The standard pattern is to listen for visibilitychange on the document and request a new lock when the page becomes visible again, as long as the user still wants the screen to stay on. Screen Awake does this automatically, which is why a session resumes when you return to the tab.

Other reasons a lock can end include the device switching to power saving, the user locking the device manually, or the browser reclaiming resources. In all cases the sentinel's released property becomes true, and the page can decide whether to ask again.

What happens when the API is not available

On older browsers and some embedded web views there is no navigator.wakeLock. The long-standing workaround is to play a tiny, silent, looping video: browsers do not sleep the display while a video is playing, so a muted clip held in the page produces the same effect. It is heavier than a real wake lock, which is why it should only be a fallback. Screen Awake prefers the native API and switches to the video method only when it has to.

Practical tips for developers

1. Request the lock in response to a user gesture such as a button press. Some browsers require this.
2. Keep the sentinel in a variable and release it when the feature is switched off.
3. Re-acquire on visibilitychange, but only when the user's setting is still on.
4. Show the current state clearly, so people know when the device will not sleep and can turn it off to save battery.
5. Provide a time limit option. A lock that is forgotten overnight drains a battery quickly.

The short version

The Wake Lock API is a polite way to say "the user is still looking at this page". It is fast, requires no install, and respects the user's battery and privacy, which is why it is the best default for any tool that needs to keep a screen on.