What Web Push is and how it works

Web Push is the web standard that lets a site send notifications to a user's browser even when none of its pages are open, with no native app and no app store. The user grants permission once, the browser creates a subscription, and whenever something relevant happens your product sends a system notification that brings them back to your site with one tap.

In short:

• Four actors take part: your site, the user's browser, the browser vendor's push service and the sender (a provider or your own server).
• The flow is always the same: permission, subscription, send, notification and click.
• You need HTTPS, a service worker and a permission the user grants through their own gesture.
• It works on desktop and Android; on iPhone and iPad, since iOS 16.4 and only when the site has been added to the Home Screen.
• It's built for short, timely, personal alerts, not for syncing data or long messages.

The four actors in Web Push

There are four pieces, and each has a clear job:

You don't pick the push service; it comes with the browser. Chrome uses Google's, Firefox uses Mozilla's, Safari uses Apple's and Edge uses Microsoft's. They all follow the same standard, so for your product it's invisible. What you do choose is who acts as the sender: build that part yourself or hand it to a service.

The full flow, from permission to click

Every alert goes through five steps. Picture an online store that wants to tell customers when their order ships:

1. Permission. On the order page, a button says "Notify me when it ships". The user clicks it and the browser shows its permission dialog.
2. Subscription. If they accept, the browser registers with its push service and returns a subscription: a unique address for that browser on that site. The sender stores it linked to the user.
3. Send. A few days later your backend sees the order has shipped and requests a send: "to this user, with this title and this link".
4. Notification. The push service delivers the message to the device. The browser wakes your site's service worker, even with no tab open, and it shows the notification.
5. Click. The user taps it and the service worker opens the tracking page, or focuses the tab if it was already open.

Along the way, messages are encrypted end to end and the sender identifies itself with a VAPID key pair, so the push service carries the alert without being able to read it and nobody else can message your subscribers. Why those keys matter so much is covered in VAPID keys explained.

What your site needs

• HTTPS. Service workers and the Push API only exist in secure contexts. During development localhost counts as secure; a local network IP over plain HTTP doesn't.
• A service worker. It's a JavaScript file on your domain that the browser runs in the background: it receives pushes, shows the notification and handles the click. We explain its role in the service worker in push notifications.
• Permission requested from a gesture. Safari and Firefox only show the dialog when you ask in response to a click or tap, and Chrome shows a quieter version of the prompt on sites whose requests usually get denied.
• A visible notification for every push. Browsers don't allow silent pushes: every message has to end in something the user sees.

Permission is the most fragile resource you have. If the user clicks "Block", only they can undo it from the site settings, and almost nobody does. That's why it pays to show your own message first ("Want a heads-up when your order ships?") and open the browser dialog only once the user has already said yes.

Where it works

iPhone is the case that surprises people most. A regular Safari tab gets no push at all: the user has to tap Share, then "Add to Home Screen", open the site from that icon and grant permission there. Apple explains the details in the WebKit announcement.

What if the device is off? The push service keeps the message for the time to live (TTL) the sender sets and delivers it when the device reconnects. "Your order has shipped" can wait a day; "your taxi is outside" is useless after a few minutes.

What it's good for, and its limits

Web Push shines when the alert is short, timely and personal:

• Transactional: payment received, order shipped, appointment confirmed.
• Alerts the user asked for: price drop, back in stock, a reply to their comment.
• Dated reminders: your booking is tomorrow, your free trial ends in three days.

It also has limits worth knowing before you design the feature:

• Little room: the encrypted message can't exceed 4096 bytes. That fits a title, a short body, a link and some data; if you need more, send an ID and let the page load the rest.
• Delivered isn't read: a Focus mode or a closed desktop browser delays or hides an alert even after it arrives.
• Subscriptions expire: when a user revokes permission or clears browser data, their subscription stops existing and has to come off the list.
• Limited attention: every irrelevant alert brings the user closer to turning them off.

Where castly fits

The sender side (storing subscriptions, encrypting, identifying yourself to every push service, delivering, retiring expired subscriptions and knowing what arrived) is the most work and the least differentiating part of your product. castly covers it with three pieces. On your site, the SDK and a button:

<script src="https://castly.sh/sdk/v1/castly.js"></script>
<script>
  Castly.init({ publicKey: 'pk_live_…' });
  document.querySelector('#notify-me').addEventListener('click', () =>
    Castly.subscribe({ userId: 'user_123' })
  );
</script>

At your site's root, a one-line /castly-sw.js file:

importScripts('https://castly.sh/sdk/v1/sw.js');

And in your backend, one call when the order ships:

curl https://castly.sh/v1/notifications \
  -H "Authorization: Bearer $CASTLY_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to":{"type":"users","userIds":["user_123"]},"title":"Your order is on its way","url":"https://shop.example/orders/8421"}'

The API answers 202 right away, delivery to each device happens in the background, and the dashboard shows each alert move from sent to delivered and clicked. The quickstart walks you through it.

Frequently asked questions

Does Web Push require Firebase?

No. Chrome uses Google's infrastructure as its push service, but you don't need a Firebase account, project or SDK. The standard works the same way in every supported browser.

Do notifications arrive when the site is closed?

Yes, because the browser wakes the service worker when a message arrives. On Android the device only needs to be on and connected. On desktop the browser must be running; if it isn't, the alert waits at the push service until it starts, as long as its TTL hasn't run out.

Can I send a push without showing a notification?

No. Browsers expect a visible notification for every message and penalize sites that don't show one. If you want to sync data in the background, Web Push is the wrong tool.

How is Web Push different from native app notifications?

They look the same on screen, but the channel differs: Web Push uses the subscription of a browser or an installed web app, while a native app uses its platform's notification system with its own token. With Web Push you don't ship anything through an app store.

Do I need a PWA to use Web Push?

On desktop and Android, no: a site served over HTTPS with a service worker is enough. On iPhone and iPad, in practice yes, because push only works once the site is on the Home Screen, and for that it should have a web app manifest.