You have received them a thousand times: that small card sliding in at the top of your screen or among your phone's notifications, carrying a headline, an offer, a reminder. If it came from a website rather than an app, it was a web push notification. In this guide we take the mechanism apart piece by piece: what they are, how they travel, what it takes to send them, and what is true (and false) in the common beliefs surrounding them.
The definition, no fluff
A web push notification is a message that a website sends to the browser of a person who gave explicit consent, and that arrives even when the site is closed. No app to install, no phone number, no email address: the channel is the browser itself, on desktop and mobile alike.
The three properties that define it:
- Explicit opt-in: nobody can send you web push unless you clicked "Allow" on the browser's request. It is the marketing channel with the cleanest consent in existence.
- Off-site delivery: the message lands on the device, not on a page. Recipients don't need to be on your site, or to have opened it recently.
- Unilateral revocation: users can switch everything off at any moment from their browser settings, without asking anyone.
How it works: a notification's journey
Behind the apparent simplicity there is a four-actor chain, and knowing it explains almost every "strange" push behavior you will ever meet.
1. The site asks, the browser keeps. When you accept notifications on a site, the browser generates a "push subscription": a unique, encrypted delivery address tied to that site on that browser on that device. No personal data involved: no name, no email. That is why these identifiers are called pseudonymous.
2. The service worker listens. The site installs a small JavaScript file in your browser, the service worker, which is the only component allowed to receive pushes and display them. It lives in the browser, sleeps when idle, and wakes up when a message arrives, even with the site closed.
3. The browser's push service plays postman. Every browser vendor runs a delivery service (Google for Chrome, Mozilla for Firefox, Apple for Safari). When a site sends a notification, it goes through the push service, which forwards it to the right device as soon as it is online. If the device is off, the message waits, within an expiry window called TTL.
4. The platform orchestrates. In theory a site could talk to push services directly; in practice you need cryptographic keys, subscriber management, segmentation, analytics and a lot of plumbing. That is what platforms like Natom do: the site installs one snippet, and the platform handles subscriptions, sending, audiences and numbers.
What a notification can contain
The standard anatomy: a title (it does ~90% of the work), a short body, an icon (usually the site's logo), an optional large image, and the destination URL that opens on click. On this skeleton lives the whole difference between a push that gets clicked and one that gets ignored.
Where it works (and the iPhone case)
On desktop (Windows, macOS, Linux) web push works across every major browser: Chrome, Firefox, Edge, Opera and Safari. On Android likewise, with the most complete experience. The special case is iOS: Apple supports web push only for sites added to the Home Screen as web apps. Translated: on iPhone the channel exists but real coverage is low, and this limit is identical for every platform, whatever anyone tells you.
Is web push legal? GDPR and consent
Yes, and it is among the cleanest channels from a regulatory standpoint, by the very way the mechanism works:
- consent is explicit, prior and granular (the browser's "Allow" click);
- no direct personal data is collected: the identifier is a pseudonymous technical token;
- revocation sits in the user's hands, at any time, from the browser settings.
Two duties remain for whoever uses the channel: mention push in your privacy policy, and don't abuse the channel itself.
Three myths worth burying
"Push is spam." Spam is unsolicited mail; pushes only reach people who clicked "Allow". They can become annoying when frequency gets abused or everything gets blasted to everyone, but that is bad use of the channel, not the channel: the fix is called segmentation.
"Nobody accepts them anyway." Subscription rates depend almost entirely on how you ask. A native request fired on landing gets declined en masse; a custom prompt shown at the right moment converts many times better.
"You can buy or import subscriber lists." Technically impossible, and that is a guarantee: every subscription is cryptographically tied to the site that collected it. Your push audience is yours by definition, and nobody can sell you one.
Why it matters, in one sentence
Every other return channel takes a toll: social has the algorithm, email has spam filters and falling open rates, apps have the installation cost. Web push is the only channel where, between you and the reader who chose to follow you, nobody stands in the middle.
Want to try it on your site? Setup takes about ten minutes: the hands-on WordPress guide is here, and the documentation covers every other stack.