Web push is the standards-based mechanism that lets an application server deliver messages to a user’s browser through a browser-operated push service, even when the website is not open in any tab. A service worker receives the message in the background and usually displays a system notification.
Among Web APIs, web push combines three pieces: the Push API, which manages subscriptions and receives messages, the Notifications API, which shows them, and the Web Push protocol with its encryption and server identification rules. Unlike WebSocket or server-sent events, it does not require an open connection from the page.
How web push delivers a message
Web push works through an intermediary push service run by the browser vendor. The application server never contacts the browser directly; it sends an encrypted message to the push service, which holds it and forwards it when the device is reachable.
- The page registers a service worker that will handle incoming push events.
- The user grants notification permission in response to a browser prompt.
- The browser creates a subscription by calling
pushManager.subscribe(), returning an endpoint URL and public keys. - The site stores the subscription on its application server.
- The server sends an encrypted request to the endpoint, signed with its VAPID key.
- The push service wakes the service worker, which fires a
pushevent and callsshowNotification().
The subscription object contains an endpoint URL that is unique to the user and browser and two keys, p256dh and auth. The server uses these keys to encrypt the payload so that the push service cannot read message contents; only the subscribed browser can decrypt them.
Protocols and parameters behind web push
Several IETF specifications define the delivery layer of web push, while W3C specifications define the browser APIs. Understanding the request parameters helps developers control delivery behavior and battery impact.
| Standard | Role | What it defines |
|---|---|---|
| Push API | Browser interface | Subscriptions and the service worker push event |
| Notifications API | Browser interface | Displaying system notifications |
| RFC 8030 | Delivery protocol | How servers send messages to push services |
| RFC 8291 | Message encryption | End-to-end payload encryption with aes128gcm |
| RFC 8292 (VAPID) | Server identification | Signed tokens that identify the sending server |
Each push request carries headers that control delivery. These parameters let the sender trade timeliness against device power consumption.
| Parameter | Typical values | Effect |
|---|---|---|
| TTL | 0 seconds to several weeks | How long the push service stores an undelivered message |
| Urgency | very-low, low, normal, high | Lets the device defer low-priority messages to save battery |
| Topic | Short label | Replaces an earlier pending message with the same topic |
| Payload size | About 4 KB maximum | Larger content must be fetched by the service worker |
Web push compared with other real-time Web APIs
Web push solves a different problem from live connection APIs. WebSocket and server-sent events push data to a page that is currently open, while web push reaches a user who has left the site.
| Technology | Page must be open | Direction | Typical use |
|---|---|---|---|
| Web push | No | Server to browser via push service | Re-engagement notifications and alerts |
| WebSocket | Yes | Bidirectional | Chat, collaboration, live trading |
| Server-sent events | Yes | Server to browser | Live feeds and progress updates |
| WebRTC data channels | Yes | Peer to peer | Low-latency exchange between users |
| Email or SMS | No | Outside the browser | Messages without a browser subscription |
Web push should therefore be seen as a re-engagement channel, not as a transport for application data. Messages may arrive late or be dropped when TTL expires, so critical state must never depend on push delivery.
Permission design and platform support
The permission prompt is the decisive moment for web push. Browsers increasingly suppress or quiet prompts that appear on page load without user interaction, and a user who blocks notifications usually stays blocked, because the site cannot ask again programmatically.
- Ask after a meaningful user action, such as clicking a button to follow an order or a topic.
- Explain the value first with an in-page message before triggering the browser prompt.
- Set `userVisibleOnly: true`, because major browsers require every push to show a visible notification.
- Support platform differences: on iOS and iPadOS, web push works only for web apps added to the home screen, starting with version 16.4.
- Offer an easy way to unsubscribe inside the site, which reduces blocking at the browser level.
Web push is a core capability of progressive web apps, because it lets an installed PWA behave more like a native app with background notifications.
Operational pitfalls of web push
Running web push at scale requires careful subscription hygiene. Subscriptions expire when users clear site data, revoke permission or reinstall the browser, and the push service signals this with specific HTTP responses.
| Symptom | Likely cause | Fix |
|---|---|---|
| 404 or 410 response | Subscription expired or revoked | Delete the subscription from the database |
| 403 response | Invalid or mismatched VAPID signature | Check the key pair and token claims |
| 413 response | Payload too large | Send a short message and fetch details later |
| Notifications arrive late | Low urgency or device power saving | Use higher urgency only for time-critical alerts |
| Duplicate notifications | Repeated sends without a topic or tag | Use the Topic header or notification tag |
Over-sending is the most damaging long-term mistake. Frequent irrelevant notifications lead users to block the site, and browsers may apply quieter permission interfaces to sites with low acceptance rates.
Put simply
Web push lets a website tap you on the shoulder after you have left it. If you agree, the site can send a short alert that appears on your screen like a message from an app, even when its page is closed.
It works a little like a mailroom run by your browser. The website drops a sealed envelope at the mailroom, and the mailroom delivers it to your device when it can. Nobody in the mailroom can read the letter, and you can cancel the delivery at any time in your browser settings.
In practice
A regional public transport operator adds web push to its journey planner. Instead of asking for permission on the home page, it shows a Notify me about delays button next to each saved route. Only users who click the button see the browser prompt, so acceptance is high and complaints are rare.
When a train on a saved route is delayed by more than 10 minutes, the server sends a push with high urgency and a TTL of 15 minutes, because an old delay alert is useless. A Topic header per route ensures that a newer update replaces an older pending one. The server also removes subscriptions that return 410 responses, keeping the database clean and the sending costs predictable.