A practical pattern for coordinating session-expiry messages across tabs.

Give the timeout an explanation

Imagine someone working with the same application in two tabs. Their session expires, and one tab sends them to sign-in while the other still looks active. The goal is to give both tabs a clear explanation and a consistent route back into the application.

A useful message is: “Your session has expired. Sign in again to continue.” The storage mechanism coordinates that interface state; the application’s authentication flow remains responsible for checking the session.

Two storage areas, different lifetimes

localStorage persists within an origin and browser profile. It does not synchronize data across devices. sessionStorage is scoped to an origin and a top-level tab; it survives reloads for that page session. It is not shared state between tabs.

Notify other tabs; update this one directly

A localStorage change can notify other same-origin tabs through the storage event. The tab making the change does not receive that event, so it must update its own interface directly.

For logout, a fresh notification value lets other tabs react even when logout has happened before. Each tab can keep its own explanatory banner in sessionStorage. A successful sign-in should clear obsolete messages and validate the new session with the server.

A practical sequence

When a tab confirms that the session has expired, it updates its own interface and emits a fresh logout notification through localStorage. Other open tabs receive the storage event and recheck their session before changing their interface.

Each tab can retain its explanation in sessionStorage across a reload. On initial page load, validate the session before trusting an old notification. After successful sign-in, clear obsolete local messages so the user does not see a timeout banner for a session that is now valid.

Storage is a signal, not authorization

Keep the server session authoritative. Do not treat a stored flag as proof that someone is authenticated, and do not store credentials in the logout signal. Browser storage can be unavailable, so session validation and a usable sign-in screen must work without it.

Do not rely on closing a tab to clear shared logout state. A stale notification should lead to a fresh session check, not an unconditional assumption about the user’s current authentication state.

Technical references

The revised behavior follows the browser API documentation linked below.