A website can reach your browser after its tab is closed. That sounds broader than it is, but it deserves a clear explanation. The Push API creates a subscription that lets an application server send an encrypted message through a push service to a browser.
The page does not stay open in the background. A service worker wakes when a message arrives, handles a small event, and may show a notification. The useful question is not whether the site is “running.” It is who can send, what intermediaries can observe, and how you end the relationship.
How browser Push API privacy works
The Push API lets a web application subscribe to messages from a server even when the app is not in the foreground or currently loaded. A registered service worker receives the event. The worker can update local state or ask the browser to display a notification.
When a subscription is created, the browser returns an endpoint plus cryptographic key material. The application sends those subscription details to its server. Later, that server addresses messages to the endpoint, and a push service routes them to the correct browser.
Each subscription belongs to a service worker registration for one origin. The endpoint is a capability URL: anyone who knows the necessary subscription details may be able to ask the push service to deliver a message. Applications need to protect it as carefully as a secret.
Push messages and notifications are related, not identical
A push message is data delivered to the web application. A notification is the visible interface the browser may show to the user. The APIs are separate, even though web push is commonly used to trigger notifications.
Browser permission and platform rules limit how sites use the capability. Many browsers tie push subscription to notification permission or require user interaction before asking. Implementations also restrict silent background use because invisible delivery could become a tracking and resource-abuse channel.
This is why a request that says “Allow notifications” can create a longer-lived channel than its wording suggests. It may enable the site to maintain a push subscription and wake its service worker when messages arrive.
What the push service can observe
The W3C Push API specification requires message payloads to be encrypted. The push service routes the message but should not receive its readable contents.
Encryption does not hide all metadata. The push service can observe timing, frequency, and message size. It must know which subscription endpoint should receive the delivery. Those patterns may reveal that a particular application is active even when the content remains unreadable.
The specification notes that padding can reduce what message size reveals, but timing and frequency are harder to conceal. A browser may choose the push service, and users may not be able to change it independently.
Why a closed tab can still receive a message
Service workers are event-driven. The browser can start the worker when a push arrives, let it handle the event, then stop it again. The site does not receive an unrestricted, permanently running background process.
This model saves resources compared with keeping a live connection open. It also means delivery can happen after you have forgotten the original tab. A subscription can survive ordinary page closure and browser restarts until it expires, is unsubscribed, or loses permission.
Our guide to service workers explains the broader lifecycle. Push is one event source among several, but it is unusual because a remote server can initiate the wake-up.
Push is different from Background Sync
Background Sync lets a site retry work that your browser already knows about, such as sending a message after connectivity returns. Push begins with an application server deciding there is new information to deliver.
That distinction matters for control. A sync task is connected to an action already taken on the device. A push subscription creates an ongoing address for future server-initiated events. Read our Background Sync guide for the companion model.
Before allowing web push
Connect permission to a specific benefit
Delivery updates, incoming calls, account security alerts, and time-sensitive collaboration can justify push. A generic content page asking before you have read anything usually cannot. Deny first if the value is unclear.
Prefer in-app controls as well
A mature service lets you choose which categories it sends, not merely all or nothing. Disable promotions while keeping security alerts. Browser permission is the final boundary; product settings make that boundary more useful.
Review old permissions
Subscriptions can outlast your interest in a service. Periodically open site settings and remove notification access from sites you no longer use. Our browser permissions guide offers a practical review routine.
Watch for repeated or deceptive prompts
A site should explain the feature before triggering the browser request. Do not grant access merely to dismiss an overlay. If a page blocks ordinary reading until you accept notifications, that pressure is useful information about the relationship it wants.
What revocation should do
When push permission is revoked, the browser can deactivate affected subscriptions. A deactivated endpoint must not be reused for another subscription. That rule prevents an old identifier from becoming a tracking handle that follows the user into a new relationship.
Unsubscribing inside the service is also valuable because it tells the application server to stop sending. Use both controls when available: switch off the category or account setting, then remove browser permission if you no longer want the site to have a push channel.
A channel worth granting carefully
Web push is efficient precisely because it reaches beyond the open tab. Encryption protects content from the routing service, while browser permission and service-worker isolation limit the application. Metadata, interruption, and long-lived subscriptions remain real costs.
Grant push to services that have something genuinely timely to say. Tune the categories. Revoke access when the relationship ends. A quiet browser is not a browser with no capabilities; it is one where each capability has a clear purpose.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.