Summary

  • W3C’s Web Locks first public draft of 5 January 2023 offered asynchronous, named locks for cooperating windows and workers sharing a storage bucket. The 24 September 2025 Working Draft kept the core pattern: request a lock, do work in a callback, release it when that work finishes.
  • An exclusive lock keeps another holder of the same name outside; shared locks allow several compatible holders. The exceptional steal option can break the old holder’s claim without stopping its code, so the turnstile coordinates cooperative work rather than proving a finished, correct transaction.

Two tabs of the same editor can both believe they are the one responsible for saving the next change. The race is easy to miss because each tab looks healthy in isolation. The trouble appears only when their actions overlap: one syncs stale state while the other updates it, or both try to clean the same local queue. A server can settle conflicts after the fact, but the browser already hosts the two contenders. Why wait for the quarrel to travel across the network?

The W3C First Public Working Draft of 5 January 2023 introduced Web Locks as a way for script to acquire a lock asynchronously over a named resource, hold it during work, then release it. Windows and workers of an application can use this mechanism to coordinate. The document describes a lock manager for agents sharing a storage bucket, potentially across separate processes. The name is chosen by the application and represents an abstract resource. A lock called document-sync is a promise about who may enter that named piece of work; it is not a lock placed on a physical file by the operating system.

The W3C publication history anchors the sequence: first public draft in January 2023, another Working Draft in September 2025. The 24 September 2025 draft gives a compact usage rhythm. Request the lock. Perform asynchronous work while holding it. Release follows when the task completes. The draft’s motivating editor example opens one document in two tabs and needs to coordinate persistence and synchronization. It also describes a primary tab holding a lock for a background job, with another tab waiting to take over if the first closes or crashes.

The lock name is the meeting point. Tabs that use the same name and storage bucket meet at the same browser-managed queue. An exclusive lock allows one holder of that name; another request must wait. A shared lock can coexist with other shared holders, while an exclusive claimant needs its own turn. This is the old readers-and-writer problem in a web coat. The browser supplies the turnstile; the application decides what a particular name stands for, and whether a job should be exclusive or shared.

The working group’s explainer makes the cooperative nature vivid. Code requests a named lock and runs inside a callback. The promise returned by the request reflects the callback’s result. A diagnostic snapshot can show held and pending locks, but its state may change as soon as it is read. The explainer also warns about deadlocks: one script can hold A while waiting for B, while another holds B and waits for A. A browser can manage the queue faithfully and still find itself hosting two applications that designed an impossible handshake.

The most interesting emergency exit is steal. The 2025 draft says a stealing request releases held locks of the same name and jumps ahead of queued requests. The explainer gives the catch: code in the old tab may continue to run while believing it still owns the lock. In that moment, the velvet rope has moved but the first worker has not left the room. Treating steal as a routine cure for slow work would turn a coordination tool into a source of overlapping work.

The browser’s help also has a defined geography. The drafts place cooperation among agents sharing a storage bucket in one user agent; separate browser profiles and private sessions occupy separate worlds. A Web Lock therefore cannot settle competition among every device, every server, or every user who opens the same document. The four original records define the API and its publication path. They do not count deployments, promise transaction durability, or prove that a particular synchronization completed correctly. The ticket governs entry. The work behind the door still belongs to the application.