Storage Event

The `storage` event lets a web page learn about Web Storage changes made by another same-origin browsing context. The context that performs the change does not receive its own `storage` event.

The `storage` event is dispatched when a `localStorage` or `sessionStorage` entry is changed, removed, or the relevant storage is cleared. The event is delivered to other browsing contexts that can access the affected storage, subject to the storage type and origin rules.

For `localStorage`, a change can notify other same-origin windows, tabs, or frames. This makes it useful for lightweight cross-tab coordination, such as reflecting a changed preference or authentication-related UI state. The page that calls `setItem()`, `removeItem()`, or `clear()` does not receive the corresponding event.

The event object provides `key`, `oldValue`, `newValue`, `storageArea`, and `url`. For `clear()`, `key`, `oldValue`, and `newValue` are `null`. For an insertion, `oldValue` is `null`; for a removal, `newValue` is `null`.

`sessionStorage` has narrower propagation behavior because it is partitioned by browsing context in addition to origin. In practice, `localStorage` is the more common choice when the goal is communication between separate tabs or windows of the same origin. The event is notification-based rather than a general-purpose messaging API.

Key points

• The modifying context does not receive its own `storage` event.
• `localStorage` changes can notify other same-origin browsing contexts.
• The event exposes `key`, `oldValue`, `newValue`, `storageArea`, and `url`.
• `clear()` produces an event with `key`, `oldValue`, and `newValue` set to `null`.
• The event is useful for synchronizing lightweight Web Storage-backed state across contexts.

Interview questions

When does the `storage` event fire?

It fires when a Web Storage area changes, such as through `setItem()`, `removeItem()`, or `clear()`. For `localStorage`, eligible other same-origin browsing contexts can receive the event. The context that performed the mutation does not receive its own corresponding event.

Why doesn't a `storage` event fire in the tab that changed `localStorage`?

The event is intended to notify other relevant browsing contexts about a storage mutation. The context performing the mutation already knows that it changed storage, so it is not notified through its own `storage` listener. If the initiating page also needs local state updated, its code should update that state directly.

What information does a `StorageEvent` provide?

Important fields include `key`, `oldValue`, `newValue`, `storageArea`, and `url`. The values describe the state before and after the change. For a `clear()` operation, the key and old/new values are `null`, so consumers must account for that case.

How would you use the `storage` event to synchronize a preference across tabs?

Each tab can listen for `storage` events and react when the relevant key changes. A tab that changes the preference writes the new serialized value to `localStorage`, causing other eligible same-origin contexts to receive the event. The initiating tab should update its own UI separately because it will not receive the event. For more complex or high-frequency messaging, a dedicated channel such as `BroadcastChannel` may be more appropriate.