Web Push Notifications: How They Work, Browser Support and Best Practices

Web push notifications reach people who are not on your website at all. A visitor reads an article on Monday, allows notifications, and on Thursday a message appears on their phone or desktop even though the browser tab is closed. For publishers, ecommerce sites and any business without a mobile app, it is a way to bring people back without needing their email address or app install. It is also one of the easiest channels to misuse, because the permission prompt appears in front of strangers. This guide explains how web push works, what you need to set it up, how to ask permission without being blocked, which messages work, how browser support varies and how web push compares with app push, email and SMS.

What are web push notifications?

Web push notifications are messages that a website sends to a subscriber’s browser, delivered through the browser vendor’s push service, and shown by the operating system as a notification. They rely on the browser’s Push API and notifications features, and on a background script called a service worker. They are a cousin of mobile push notifications but work without an app. If you do have an app, read our guide to push notifications.

How web push works

1. The site registers a service worker. A small script that the browser keeps and can wake in the background.
2. The visitor is asked for permission. The browser shows its own prompt. The site cannot style it.
3. The browser creates a subscription. It contains an endpoint URL for that browser and keys for encryption.
4. Your server stores the subscription. Linked to the visitor’s profile where possible.
5. You send a message. Your server posts an encrypted payload to the endpoint, authenticated with your server keys.
6. The browser push service delivers it. Even if the site is closed, as long as the browser can run.
7. The service worker shows the notification. And handles the click by opening or focusing a page.

// Simplified illustration of a subscription flow
const reg = await navigator.serviceWorker.register('/sw.js');
const permission = await Notification.requestPermission();
if (permission === 'granted') {
  const sub = await reg.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: PUBLIC_VAPID_KEY
  });
  await fetch('/api/push/subscribe', { method: 'POST', body: JSON.stringify(sub) });
}

// sw.js
self.addEventListener('push', e => {
  const d = e.data.json();
  e.waitUntil(self.registration.showNotification(d.title, { body: d.body, data: { url: d.url } }));
});
self.addEventListener('notificationclick', e => {
  e.notification.close();
  e.waitUntil(clients.openWindow(e.notification.data.url));
});

The code is a sketch to show the pieces, not production code. The VAPID keys identify your server to the push services, and the details are defined in web standards. Your developers or your platform’s SDK handle the rest.

Browser and device support

Support has changed over the years and still differs by browser, operating system and whether the site is installed as a progressive web app. Desktop Chrome, Edge and Firefox have supported web push for a long time. Android browsers generally support it too. On Apple devices, support has historically been more limited and has depended on the OS version and, for iPhones, on the site being added to the home screen, so verify the current position in Apple’s and your platform’s documentation before planning a campaign. Never assume that every visitor can receive web push.

Asking for permission without being blocked

Browsers are strict about permission because sites have abused it. Many browsers now suppress or quiet the prompt on sites that users routinely decline, and a blocked site is hard to recover. The same principles as for app push apply, as covered in push opt-in rates, but with added care.

• Never ask on page load. The visitor knows nothing about you yet.
• Use a soft prompt first. A message on the page, styled by you, explains the value and offers “Yes, notify me” and “Not now”. Only trigger the browser prompt after a yes.
• Ask after value. For example after reading a second article, or when viewing an out-of-stock product.
• Be specific. “Tell me when this is back in stock” beats “Allow notifications”.
• Remember a no. Do not show the soft prompt again for a while.

Messages that work on web push

Web push is best for timely, low-effort messages with a clear destination. Tie each message to visitor behaviour using event-triggered marketing, set frequency caps and measure results by clicks, return visits and conversions rather than sends. For message copy, see push notification examples.

Web push vs app push vs email vs SMS

A subscription is tied to a browser on a device, not to a person. One customer may have several, and clearing browser data removes it. Link subscriptions to a profile when the visitor logs in, so that web push joins your other channels. In Flowfox, the web messaging channel and push channel work with the same contact profile, so a journey can try web push first and fall back to email if the visitor is not reachable. For the decision between channels, see email vs SMS vs WhatsApp and push vs SMS.

A worked example

An online bookstore with no app wants to bring back readers who view books but do not buy. It adds a soft prompt on product pages for out-of-stock books: “Want a heads-up when this is back?”. Only people who click yes see the browser prompt. A service worker handles the notification, and the click opens the book page with the add-to-cart button ready. A journey sends one notification when stock returns and nothing afterward unless the person views another out-of-stock title. A second flow, for subscribers who have not visited for a month, sends at most one message about new arrivals in a genre they browsed. The store and flows are invented, and no results are claimed. The point is the design: ask at a moment of real need, send rarely, link straight to the item.

Privacy and compliance apply to web push as to any messaging. Be clear about what you will send, record the permission and its source, give an easy way to unsubscribe in the notification settings or on your site, and read our guides to consent management and the DPDP Act. If you serve visitors in Europe, also consider rules such as the GDPR and ask your legal adviser about your case.

Common mistakes

• Prompting on page load. It gets you blocked.
• Assuming all browsers work. Check support, especially on Apple devices.
• Sending the same broadcast to everyone. Segment by interest and behaviour.
• Ignoring identity. Anonymous subscriptions limit personalisation.
• Too many messages. Users can block your site with a click.
• No measurement. Track clicks and conversions, not sends.

Web push asks for permission from strangers. Earn it with one good reason, then keep it with restraint.

Read next: silent push notifications, customer engagement and the blog.