Wake Lock API: Browser Support, Features, Use Cases

What is the Wake Lock API?

The Wake Lock API is a W3C JavaScript API that prevents a device from dimming, locking, or turning off the screen while a web page needs it on. The Web Applications Working Group at the W3C edits the Screen Wake Lock spec, and the API is exposed on navigator.wakeLock with a single supported lock type, "screen".

Which browsers does the Wake Lock API support?

Every modern Chromium-based browser, Firefox, and Safari support the Wake Lock API on desktop, Android, iPadOS, and iOS, so global support sits above 94% as of May 2026.

What are the key features of the Wake Lock API?

The Wake Lock API is built around a single Promise-returning request method, a sentinel object you hold to keep the lock alive, and an automatic release tied to page visibility. Every call runs in a secure HTTPS context on a visible document.

• navigator.wakeLock.request("screen"): Returns a Promise that resolves to a WakeLockSentinel when the system grants the screen wake lock. The page must be visible, or the request rejects with NotAllowedError.
• WakeLockSentinel.release(): Returns a Promise that resolves once the wake lock is released. Pages call it when the user finishes the wake-lock-bound task.
• "release" event on WakeLockSentinel: Fires when the lock is released, whether the page asked or the browser auto-released on visibility change. Use it to update UI like a "screen-on" toggle.
• WakeLockSentinel.released and .type properties: Tell the page whether the lock is still active and which lock type it holds. The type value is always "screen" in current browsers.
• Auto-release on tab hidden: The browser releases the lock when document.visibilityState flips to "hidden". Re-acquire it inside a visibilitychange handler.
• Permissions-Policy: screen-wake-lock: Cross-origin iframes are blocked by default. The embedder must list screen-wake-lock in its Permissions-Policy header or on the iframe allow attribute.
• Secure context only: The API throws on HTTP and on file:// pages. Chrome, Firefox, and Safari gate navigator.wakeLock to HTTPS and to http://localhost.
• Feature detection with "wakeLock" in navigator: A single in check tells the page whether the API is wired up. Ship a NoSleep.js-style video fallback for browsers that return false.

How do you use the Wake Lock API?

The Wake Lock API is a five-step flow: feature-detect, request a screen lock from a visible page, hold the sentinel, listen for release, and re-acquire on tab focus. The whole sequence sits inside one async function.

• Feature-detect support: Run "wakeLock" in navigator before you call request, so unsupported browsers fall back cleanly to a NoSleep.js video loop.
• Call navigator.wakeLock.request("screen"): Make the call from a click handler or from a page that is currently visible. Some browsers reject silent background requests with NotAllowedError.
• Store the WakeLockSentinel reference: Keep the resolved sentinel in a module-scope variable so later code can call sentinel.release() and so the garbage collector does not drop the lock.
• Listen for the release event: Wire sentinel.addEventListener("release", handler) so the page can update UI like a "screen-on" badge when the browser or the user releases the lock.
• Re-acquire on visibilitychange: Add a document.addEventListener("visibilitychange", handler) that calls request("screen") again when document.visibilityState flips back to "visible". The browser drops the lock on hidden tabs.
• Release the lock when done: Call await sentinel.release() when the user finishes the wake-lock-bound task, such as exiting cooking mode or closing a slide deck. Holding it longer wastes battery.

Paste this snippet into the DevTools console of Chrome, Edge, Firefox, or Safari over HTTPS. Click anywhere on the page once and the console logs a confirmation that the screen wake lock is active.

// Paste this into the DevTools console of Chrome, Edge, Firefox, or Safari over HTTPS.
// The page must be visible and you must run it from a user gesture for some browsers.
let screenLock = null;

if ("wakeLock" in navigator) {
  console.log("Wake Lock API is available.");

  document.body.addEventListener("click", async () => {
    try {
      screenLock = await navigator.wakeLock.request("screen");
      console.log("Screen wake lock acquired. Screen will stay on.");

      screenLock.addEventListener("release", () => {
        console.log("Screen wake lock released. Screen can sleep again.");
      });
    } catch (err) {
      console.error("Wake lock request failed:", err.name, err.message);
    }
  }, { once: true });

  document.addEventListener("visibilitychange", async () => {
    if (screenLock !== null && document.visibilityState === "visible") {
      screenLock = await navigator.wakeLock.request("screen");
      console.log("Screen wake lock re-acquired after tab focus.");
    }
  });
} else {
  console.log("Wake Lock API is not supported in this browser.");
}

If the console prints "Wake Lock API is not supported in this browser", you are on an older iOS, an older Firefox, or a legacy Android Browser. Ship a NoSleep.js-style video fallback for those visitors.

What are the use cases of the Wake Lock API?

The Wake Lock API is the right fit for any web app that needs the screen on without a constant tap. Production sites already use it for cooking, navigation, presentations, ticketing, and live streams.

• Recipe and cooking apps: Keep the screen on while users follow steps with floury or wet hands. Sites like Bon Appetit, Delish, and home-grown recipe PWAs hold a wake lock during the active recipe view.
• Maps and turn-by-turn navigation: Hold the screen on while a cyclist or driver follows a route. Web map apps acquire the lock when navigation starts and release it on arrival.
• Presentations and slide decks: Slides.com, Reveal.js, and Google Slides Web hold a screen wake lock during a live talk so the laptop never dims mid-sentence.
• Boarding passes, tickets, and QR codes: Airline web apps and event ticket pages keep the screen lit until the gate or door scanner reads the barcode.
• Live streams and long-form video: Streaming sites pair the lock with the playing state, so YouTube-style web players match native-app behavior on Android and iOS.
• Games using motion or voice input: Web games that read deviceorientation or use the SpeechRecognition API need the screen on without a finger touch between gestures.
• Reading apps and ebook readers: Web readers hold the lock while a chapter is open, so a long read on a phone does not get cut by the system idle timer.

What are the known issues with the Wake Lock API?

The Wake Lock API is well-supported, but the rough edges show up around auto-release on tab hidden, the missing system lock type, and a handful of OS-level power-saver overrides that no web API can defeat.

• Auto-release on hidden tabs: The browser drops the lock the moment document.visibilityState flips to "hidden". Pages must re-acquire it inside a visibilitychange handler, or the screen sleeps when the user tabs away and back.
• No system wake lock: Only the "screen" type is supported. The earlier draft defined a "system" lock that kept the CPU alive, but no browser shipped it. Move long-running CPU work to a Service Worker or backend job.
• HTTPS and visible-document gates: The API throws NotAllowedError on http://, on file://, and on hidden tabs. Background iframes also need a Permissions-Policy: screen-wake-lock opt-in.
• OS power-saver wins: A device in Low Power Mode on iOS, Battery Saver on Android, or Power Saver on Windows still dims and locks the screen even when a wake lock is active. The lock is a request, not a guarantee.
• Older Firefox needs a flag: Firefox 124 and 125 keep the API behind dom.screenwakelock.enabled in about:config, so feature-detect and fall back.
• Older iOS has no fallback: iOS 16.3 and earlier never shipped the API, and Apple's WebKit-only rule means Chrome and Edge on those iPhones inherit the gap. NoSleep.js is the only workaround.
• The released property is not reactive: WakeLockSentinel.released only flips after the release event fires, so polling it in a loop is wrong. Wire the "release" event listener to update UI instead.

In my experience, the trap that bites every Wake Lock integration once is the auto-release on tab hidden. A user opens a recipe, switches to messages, and switches back, and the screen sleeps because the lock died with the visibility flip. Wire visibilitychange to re-request the lock and the surprise goes away.

Citations

All Wake Lock API version numbers and platform notes in this guide come from these primary sources:

• MDN Web Docs - Screen Wake Lock API: developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API
• MDN Web Docs - WakeLock interface: developer.mozilla.org/en-US/docs/Web/API/WakeLock
• MDN Web Docs - WakeLockSentinel interface: developer.mozilla.org/en-US/docs/Web/API/WakeLockSentinel
• W3C Screen Wake Lock specification: w3.org/TR/screen-wake-lock
• W3C Screen Wake Lock editor's draft: w3c.github.io/screen-wake-lock
• Chrome for Developers - Stay awake with the Screen Wake Lock API: developer.chrome.com/docs/capabilities/web-apis/wake-lock
• Chrome Platform Status - Screen Wake Lock API: chromestatus.com/feature/4636879949398016
• WebKit blog - WebKit Features in Safari 16.4: webkit.org/blog/13966/webkit-features-in-safari-16-4
• Firefox 126 release notes: firefox.com/en-US/firefox/126.0/releasenotes
• web.dev - Screen Wake Lock API supported in all browsers: web.dev/blog/screen-wake-lock-supported-in-all-browsers
• Mozilla Bugzilla - Screen Wake Lock API tracking bug: bugzilla.mozilla.org/show_bug.cgi?id=1589554