The Web Locks API keeps browser tabs from colliding
Open the same web app in two tabs and both copies may try to do the same work. They can sync the same records, refresh the same cache, or write competing updates to local storage. The Web Locks API gives those tabs and workers a way to coordinate without guessing which one should go first.
The name sounds like a security feature. It is really a scheduling tool. A lock does not encrypt data, authenticate a user, or stop another website from acting. It lets scripts from the same origin agree that one task should have temporary control of a named resource.
What the Web Locks API does
A page requests a lock through navigator.locks.request(). It supplies a name chosen by the application and a callback containing the work. When the lock becomes available, the browser runs the callback. The lock is released when that callback finishes.
The MDN Web Locks API guide explains that requests for the same named lock are queued across tabs and workers from the same origin. If one tab is syncing an IndexedDB database, another can wait rather than launching a competing sync.
The W3C Web Locks draft defines the API as an asynchronous coordination mechanism. It supports exclusive locks, shared locks, conditional requests, abort signals, and a query method for inspecting current lock state.
A lock name is an agreement inside one site
Web Locks operate on abstract names. A developer might choose database-sync, leader-election, or draft-save. The browser does not know what those names mean. It only ensures that requests using the same name follow the selected rules.
The scope is crucial. A lock created by one origin does not block a different origin. A banking site cannot freeze work on a news site, and an embedded third-party frame should not gain a communication path outside its storage boundary. Locks follow the same privacy partitions that separate site data.
This builds on the principles in our explanation of how the same-origin policy protects web data. Coordination is useful precisely because it stays inside an origin's own lane.
Exclusive and shared locks solve different problems
Exclusive locks allow one writer
The default mode is exclusive. Only one matching lock can be held at a time. This suits tasks that must not overlap: migrating a local database, choosing a single tab to maintain a connection, or applying a batch of updates in order.
Shared locks allow several readers
Shared mode lets multiple compatible requests proceed together, while an exclusive request waits. It resembles the reader-writer pattern used in databases. Several tabs might read a stable resource at once, but a write operation needs a quiet moment.
Neither mode automatically protects the underlying data. The application must place the relevant work inside the callback and use consistent names. A misspelled lock name is simply a different lock.
Where users feel the benefit
Good coordination is almost invisible. A note-taking app stops uploading the same edit twice. A music service avoids two tabs both claiming to be the active controller. An offline app performs one cache cleanup instead of several. A dashboard elects one tab to receive updates, then shares the result locally.
These patterns matter more as websites behave like installed software. Service workers, IndexedDB, background tasks, and multiple windows all share responsibility for state. Our guide to service workers in the browser shows why work can continue outside the page you are looking at.
What Web Locks do not reveal
The API does not expose files, passwords, devices, location, or the contents of other tabs. It also does not let one website list locks held by unrelated sites. A page can query the lock manager for its own scope and receive a snapshot of held and pending requests.
That snapshot can include names chosen by the same application and identifiers for its own contexts. It is mainly a diagnostic tool. Because the page created the names and the work, it does not gain a new view into your broader browsing.
Private browsing sessions are kept separate from ordinary browsing for this API. That prevents a normal tab from using a lock as a signal that a private tab is open. It matches the broader boundary discussed in what private browsing does and does not protect.
Failure modes developers still need to manage
A tab can wait too long
If a lock holder performs slow work, other requests remain queued. Developers can use abort signals, timeouts, or conditional acquisition so an interface does not appear frozen. The application should show useful progress rather than hiding a blocked task.
Locks can deadlock
Two tasks can each hold one lock while waiting for the other. The browser itself continues normally, but the affected feature stops making progress. Developers reduce this risk by acquiring multiple locks in a consistent order and avoiding unnecessary nesting.
Closing a context changes leadership
If the tab holding a lock closes or its execution context ends, the browser releases the lock and can grant the next request. Applications should treat leadership as temporary. Important state belongs in durable storage, not only in the fact that a lock is held.
A checklist for responsible implementation
- Use clear, stable lock names for one narrowly defined resource.
- Keep callbacks short and place only necessary work inside them.
- Add cancellation or timeout behavior for operations that may stall.
- Acquire multiple locks in a predictable order.
- Test tab crashes, reloads, offline transitions, and private windows.
- Do not present a Web Lock as encryption or an access-control guarantee.
Web Locks can coordinate writes to browser storage, but storage itself has separate persistence, quota, and privacy rules. Our guide to why browsers partition website storage explains the surrounding boundary.
Order is a quiet form of reliability
The Web Locks API solves a narrow problem well. It gives one web application a shared queue across its tabs and workers, then stays out of the way. Users do not need to grant permission because the API does not reach beyond the site's existing scope.
For developers, the lesson is restraint. Name the resource carefully, hold it briefly, and plan for failure. When coordination is designed well, the browser feels calmer: fewer duplicate operations, fewer corrupted drafts, and less confusion about which tab is in charge.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.