Key Takeaways
- A push notification travels through exactly three stops: your website’s server, a delivery service run by the browser maker (Google, Apple, Mozilla, or Microsoft), and the subscriber’s device. There is no fourth stop unless a plugin or service adds one.
- The “delivery service” in the middle isn’t optional and isn’t something any website owner controls — every browser maker runs its own, and your server has to use whichever one matches the visitor’s browser.
- The message itself is encrypted before it leaves your server and only gets decrypted on the visitor’s device — the delivery service in the middle never sees what the notification actually says.
- A “self-hosted” push notification plugin and a “SaaS” push notification platform both use this same three-stop path. The real difference is whether a fourth company sits between your server and that path, and whether your subscriber list lives on your server or theirs.
- None of this requires a phone app, an app store, or anything installed beyond the visitor’s existing browser — the entire system runs on a web standard every major browser already has built in.
If a push notification has ever popped up on your phone from a website you visited once, weeks ago, with no app installed and no app store involved — you’ve probably wondered how that’s even possible. It feels like it should require something more complicated than it actually does. The real mechanism is simpler than most explanations make it sound, and once you see the three stops a notification actually makes, the whole thing stops feeling like magic.
The Short Version, Before the Long One
A push notification makes exactly three stops: it starts at your website’s own server, passes through a delivery service that belongs to whichever browser the visitor is using, and lands on the visitor’s device. That’s the entire trip. No app store. No phone number. No middleman company unless one’s been added on purpose.
Your website is the sender. You write a letter (the notification) and seal it in an envelope nobody but the recipient can open (encryption). You don’t deliver it yourself — you hand it to a postal carrier (the browser’s delivery service) who already knows exactly where the recipient lives, because the recipient gave that carrier their address back when they first signed up for mail (subscribed to notifications). The carrier delivers the sealed envelope. They never read what’s inside. They just know where it goes.
Different countries have different postal carriers — Google runs one, Apple runs another, Mozilla and Microsoft each run their own. Your website doesn’t get to pick; it has to use whichever carrier matches the recipient’s address. But every carrier follows the same basic delivery rules, which is why this works the same way no matter which browser someone uses.
What Actually Happens, Stop by Stop
Here’s the same trip with the technical names attached, because they’re useful once the basic shape makes sense. Google’s own developer documentation lays out this exact architecture: your server never sends a message directly to a visitor’s device. It sends a request to a push service — a delivery infrastructure controlled by the browser maker — and that service handles getting the message the rest of the way.
- Your Website’s ServerWhen you publish a new post, run a sale, or manually send a campaign, your WordPress server builds the notification — the headline, the message, the link — and encrypts it so nobody in the middle can read it. It then sends this sealed package to a push service.
- The Browser’s Push ServiceThis is the part most explanations skip past too quickly. Every browser maker runs its own delivery infrastructure: Google operates one for Chrome and Edge, Apple operates one for Safari, Mozilla operates one for Firefox. When someone subscribes to your notifications, their browser registers an address with whichever service it uses — and that’s the address your server sends to. The push service holds the encrypted message and waits for the right moment to deliver it.
- The Subscriber’s DeviceWhen the device is online and reachable, the push service hands off the encrypted message to the browser. A small background program called a service worker — which keeps running even when the website itself isn’t open — receives it, decrypts it, and displays it as the notification the visitor actually sees and taps.
Why a Notification Can Arrive Days After You Hit Send
One detail that confuses people the first time they notice it: a push notification can show up well after it was sent, especially if the recipient’s phone was off or offline at the time. This isn’t a bug — it’s the system working exactly as designed. The push service in the middle holds onto the encrypted message and keeps trying for a window of time you (or your plugin) define, commonly called the message’s time-to-live. Google’s technical documentation describes this directly: once a message is sent, the push service keeps it queued until either the device comes back online and the message gets delivered, or the message expires and gets quietly discarded.
Why the Message Stays Private the Whole Way
The middle stop in this journey — the browser’s push service — never actually sees what your notification says. The Web Push Protocol requires that any data sent through it be encrypted before it leaves your server. The push service is handed a sealed, unreadable package and a destination address — it routes the package, but it has no key to open it. Only the subscriber’s own browser, on their own device, holds the key needed to decrypt the message once it arrives.
This is the same mechanism described in how VAPID lets your server prove its identity without a third party vouching for it — the two pieces work together. VAPID is how your server signs the outgoing request so the push service knows it’s legitimate. The encryption is how the contents of that request stay private from the push service itself. Neither piece requires trusting the company running the delivery infrastructure with anything beyond “deliver this sealed envelope to this address.”
Where “Self-Hosted” and “SaaS” Actually Differ
Given that every push notification, from every plugin or platform, travels through this same three-stop path, it’s worth being precise about what changes between a “self-hosted” plugin and a SaaS push platform — because the three-stop architecture itself isn’t the differentiator. The difference is what happens before stop one and after stop three.
❌ SaaS / Vendor-Relay Pattern
- Your server sends the message to a vendor’s server first
- The vendor’s server then forwards it into the same push-service path
- Subscriber addresses are stored on the vendor’s infrastructure, not yours
- If the vendor changes pricing or shuts down, your list is at risk
✓ Directly Self-Hosted Pattern
- Your own server sends straight into the push-service path — no stop in between
- Subscriber addresses are stored only in your own database
- No company besides the browser maker ever touches the request
- Nothing about your list depends on a vendor’s continued existence
Both patterns ultimately rely on the exact same browser push services in the middle — there’s no special “SaaS lane” or “self-hosted lane” inside Chrome’s or Safari’s infrastructure. What changes is purely whether an extra company’s server sits between your website and that shared, standardized delivery path, and whether that company is the one holding your subscriber list.
The browser’s push service was never the middleman anyone needed to worry about. It’s required, it’s standardized, and it never reads your message. The actual middleman — when there is one — is a company that didn’t need to be there at all.
No App, No App Store, No Phone Number
It’s worth stating plainly what this entire mechanism does and doesn’t require, because the comparison to a native phone app causes real confusion. A native app’s push notifications go through Apple’s or Google’s app-specific notification systems, tied to an app installed from an app store. Web push notifications use a completely separate, web-based standard — the Push API, built directly into the browser itself. A visitor never downloads anything beyond the browser they already have. There’s no app to install, no app store review process, and no phone number collected — just a one-time permission prompt in the browser, after which the three-stop delivery path described above handles everything else automatically.
Further Reading
- What Is VAPID and Why It Matters for WordPress Site Owners — the standard that lets your server prove its identity to the push service without a third party vouching for it.
- What Is a Progressive Web App (PWA) for WordPress — the service worker that receives push messages is the same piece of technology that makes a site installable and able to work offline.
- Do You Need OneSignal for a WordPress Blog in 2026? — an honest look at when adding a vendor relay to this delivery path is actually worth it.
Who knew the notification that reached a phone with no app installed wasn’t magic at all — it was a sealed envelope, a postal carrier that already knew the address, and exactly three stops in between.
