navigator.locks is the entry point for the Web Locks API. Learn the LockManager, request() / query(), coordinating tabs, secure context rules, five examples, and try-it labs.
01
Kind
Read-only property
02
Returns
LockManager
03
Baseline
Widely available
04
Context
Secure (HTTPS)
05
Request
locks.request()
06
Inspect
locks.query()
Fundamentals
Introduction
Open the same web app in two tabs and both might try to sync data at once. That can corrupt IndexedDB writes or waste bandwidth. Web Locks let those tabs take turns on a named resource.
navigator.locks returns a LockManager. You call request(name, callback) to acquire a lock, do async work inside the callback, and the lock is released automatically when the callback finishes.
💡
Origin-scoped
Locks are per origin. A tab on https://example.com does not share locks with https://other.com. Workers on the same origin can use them too.
Concept
Understanding the locks Property
Think of navigator.locks as a lock desk for your origin: request a named lock, hold it while you work, then let the next waiter in.
LockManager — object returned by navigator.locks.
request(name, cb) — run cb while holding the lock.
Auto-release — when the callback (and its awaits) complete.
query() — snapshot of held and pending locks.
Modes — default exclusive; optional shared.
Secure context — HTTPS / localhost required.
Foundation
📝 Syntax
General form of the property:
JavaScript
navigator.locks
Value
A LockManager object with request() and query().
Common patterns
JavaScript
// MDN-style request (lock released when callback finishes):
navigator.locks.request("my_resource", async (lock) => {
// The lock has been acquired.
await doSomething();
// Now the lock will be released.
});
// Await the whole request (resolves after release):
await navigator.locks.request("my_resource", async (lock) => {
await doSomethingWithLock();
});
// Inspect held / pending locks:
const state = await navigator.locks.query();
Web Locks available
(or "Web Locks missing" on unsupported / insecure pages)
How It Works
On modern HTTPS browsers this is usually available. Still feature-detect for older engines.
Example 2 — Secure Context Check
Web Locks require HTTPS / localhost.
JavaScript
console.log("secure: " + window.isSecureContext);
console.log("locks: " + Boolean(navigator.locks));
if (!window.isSecureContext) {
console.log("Serve over HTTPS to use navigator.locks");
} else if (!navigator.locks) {
console.log("Secure, but Web Locks not exposed");
} else {
console.log("Ready to call request / query");
}
navigator.locks (Web Locks API) is Baseline Widely available across modern browsers (MDN: since about March 2022). Use it over HTTPS to coordinate tabs and workers on the same origin.
✓ Baseline · Widely available
Navigator.locks
Request named locks, run work in the callback, query held/pending state, and release automatically when done.
UniversalWidely available
Google ChromeAll versions · Desktop & Mobile
Full support
Mozilla FirefoxAll versions · Desktop & Mobile
Full support
Apple SafariAll versions · macOS & iOS
Full support
Microsoft EdgeAll versions · Chromium & Legacy
Full support
Internet ExplorerIE 6+ · Legacy environments
Full support
OperaAll modern versions
Full support
locksExcellent
Bottom line: Use navigator.locks.request for cross-tab coordination. Prefer ifAvailable for non-blocking leader checks.
Wrap Up
Conclusion
navigator.locks is the Web Locks entry point. Feature-detect it in a secure context, call request() with a named resource, keep critical work inside the callback, and use query() when you need a status snapshot.
Prefer async callbacks so release waits for awaits
Use ifAvailable when waiting is undesirable
Serve over HTTPS / localhost
❌ Don’t
Nest locks carelessly (deadlock risk)
Hold locks longer than needed
Assume locks work across different origins
Forget that release is tied to callback completion
Use steal unless you understand the disruption
Summary
Key Takeaways
Knowledge Unlocked
Five things to remember about locks
Baseline LockManager for coordinating tabs and workers.
5
Core concepts
🔒01
Returns
LockManager
Entry
🔓02
Request
Named lock
Hold
🔄03
Release
Auto on finish
Callback
🔍04
Query
Held / pending
Debug
✅05
Status
Baseline
HTTPS
❓ Frequently Asked Questions
It is a read-only Navigator property that returns a LockManager — the entry point for the Web Locks API so tabs and workers on the same origin can request and query named locks.
No. MDN marks it Baseline Widely available (since about March 2022). It is not Deprecated, Experimental, or Non-standard.
Yes. It is available only in secure contexts (HTTPS or localhost) in supporting browsers.
Call navigator.locks.request(name, async (lock) => { … }). The callback runs while the lock is held; when the callback finishes (including awaited work), the lock is released automatically.
navigator.locks.query() returns a Promise that resolves with a snapshot of held and pending locks for the origin — useful for debugging why a lock could not be acquired.
To coordinate work across multiple tabs or workers — for example so only one tab syncs IndexedDB to the network at a time (leader election).
Did you know?
MDN’s classic use case is leader election: every tab requests "my_net_db_sync", but only one holds the exclusive lock and performs the sync while the others wait or skip with ifAvailable.