You have seen the box. You land on a news site, and before you have read a word, a grey rectangle slides down from the top of the browser asking if example.com can send you notifications. Most people click “Block” without reading it.
Which is a shame, because underneath that badly-timed prompt is one of the few marketing channels that still works. A push notification lands on the device even when the browser is closed. No inbox to compete with, no algorithm deciding whether your subscribers see you, no per-message cost.
This post explains how it actually works — the protocol, not the marketing. If you run a site and you are deciding whether push is worth setting up, the mechanics matter, because they determine what is possible and what is not.
The one-paragraph version
Your site asks the browser for permission. If the visitor agrees, the browser generates a unique URL — an endpoint — hosted by whoever makes that browser: Google for Chrome, Mozilla for Firefox, Microsoft for Edge, Apple for Safari. Your server stores that URL along with two encryption keys. When you want to send a notification, your server encrypts the message and POSTs it to that URL. The push service delivers it to the device. A small piece of JavaScript called a service worker, which the browser keeps running in the background, receives it and displays the notification.
That is the whole thing. Everything else is detail.
The four pieces
1. The service worker
A service worker is JavaScript that runs outside any page. It has no access to the DOM, cannot touch the page the user is looking at, and — crucially — keeps running after every tab from your site is closed.
It has to be served from the root of your domain. A service worker at example.com/wp-content/plugins/thing/sw.js can only control pages under that directory, which is useless. It has to be at example.com/sw.js to control the whole site. This trips up a lot of people setting push up manually.
2. The subscription
When the visitor grants permission, the browser calls its push service and gets back three things:
- The endpoint. A long URL, unique to that browser on that device. This is the address you send to.
- A public key (
p256dh). An elliptic-curve public key, 65 bytes, used to encrypt the payload. - An auth secret (
auth). 16 random bytes used in the key derivation.
Your server stores all three. Lose them and that subscriber is gone permanently — there is no way to recover a subscription, and the person would have to opt in again.
3. The encryption
This is the part that surprises people. The push service — Google, Mozilla — relays your message but cannot read it. The payload is encrypted end-to-end between your server and the subscriber’s browser.
The scheme is specified in RFC 8291. In outline:
- Your server generates a throwaway key pair for this one message.
- It performs an ECDH key agreement with the subscriber’s public key to derive a shared secret.
- That secret, plus the auth secret, plus a random salt, goes through HKDF to produce a content encryption key and a nonce.
- The payload is encrypted with AES-128-GCM.
- The salt, the throwaway public key, and the ciphertext are concatenated and sent.
The browser reverses it. Google sees encrypted bytes and a destination.
The practical consequence: your payload has a hard size limit of about 4KB, and realistically under 3,000 bytes once you account for the encryption overhead. A title, a body, a URL and an image URL fit comfortably. A long article does not.
4. VAPID
Without some form of authentication, anyone who obtained a subscriber’s endpoint could send them notifications pretending to be you. VAPID (RFC 8292) fixes this. Your server holds a permanent key pair, signs a short JSON Web Token for each push service it talks to, and includes it in the request. The push service verifies the signature.
The important bit: VAPID keys are permanent per site. Regenerate them and every existing subscription becomes invalid. Every subscriber is gone. This is the single most destructive mistake you can make with push, and it is easy to make if you do not know it.
What push can and cannot do
Can:
- Reach a device with the browser fully closed, on desktop and Android
- Show a title, a message, an icon, a wide image and up to two action buttons
- Deep-link to any page
- Be delivered to a device that was offline, once it reconnects, if the TTL has not expired
Cannot:
- Reach an iPhone unless the visitor has added your site to their home screen. Apple supports web push from iOS 16.4, but only for installed web apps. In practice, very few people do this, so treat iOS as roughly zero.
- Be sent to someone who clicked “Block”. That decision is stored by the browser and you cannot prompt again — the visitor has to change it in browser settings, which nobody does. This is why the timing of your first prompt matters so much.
- Carry a long message. It is a headline, not an article.
- Be guaranteed delivery. Push services can and do drop messages under load, and a device that stays offline past the TTL never gets it.
Where the money goes
Nothing in the protocol above costs anything. Google does not charge to relay pushes. Mozilla does not. The infrastructure is free.
What you pay for, when you pay, is software: a service that stores your subscribers, encrypts the payloads, manages the sending queue and gives you a dashboard. The major hosted providers charge by subscriber count, typically starting free up to a few thousand and rising steeply after that. Check each provider’s pricing page for current limits.
There is nothing wrong with paying for that — running a reliable sending queue for a million subscribers is real work. But it is worth understanding that the per-subscriber fee is for the software and the servers, not for the delivery. There is no per-message cost being passed through. Which means self-hosting is genuinely viable, and at scale, dramatically cheaper.
The honest case against push
I would rather you set this up with clear eyes than sell you on it.
The prompt annoys people. Fired badly — on page load, before any content is read — it is a bad experience and gets blocked by most visitors. Fire it well, and you get a meaningfully better opt-in rate. But it is always an interruption.
Opt-in rates are modest. Somewhere in the region of 5–10% of visitors will subscribe if you ask well; a native prompt on page load does much worse. Do not budget on 30%.
Lists decay. People clear browser data, reinstall, switch devices, or simply stop clicking. Expect meaningful churn over a year even with no unsubscribes, and plan to keep adding subscribers rather than treating the list as an asset that only grows.
Click rates fall with frequency. Send daily and your click rate drops. Send five times a day and you train people to dismiss you. The channel rewards restraint in a way that email mostly does not.
None of this makes push a bad channel. It makes it a channel with a shape, and the sites that do well with it are the ones that respect the shape.
Setting it up on WordPress
You have three options.
A hosted service. OneSignal, PushEngage and similar. Fastest to set up, works well, costs money as you grow, and your subscriber list lives on their servers rather than yours.
Self-hosted on a VPS. LaraPush and similar Laravel applications. You own everything, you pay only for the server, and you need to be comfortable with a VPS, a deploy and a cron daemon.
Self-hosted inside WordPress. A plugin that keeps subscribers in your own database and sends directly. No external service, no VPS. Limited by what PHP on your host can do, which for most sites is plenty.
I built EasyPush for the third case, because the gap between “pay monthly forever” and “learn to run a Laravel app” seemed unnecessarily wide for the average WordPress publisher. It is free for unlimited subscribers and unlimited sends.
What to read next
If you have decided push is worth doing, the next question is what to actually send. Push notifications for blog traffic covers the part that decides whether this channel earns its keep: what to write, how often, and what the numbers look like when it is working.
Frequently asked questions
What are web push notifications?
Short messages a website can send to a visitor’s device after they’ve left the site, as long as the visitor agreed to receive them. They appear as a pop-up in the corner of the screen on desktop or in the notification shade on Android.
Do web push notifications cost money to send?
The delivery itself is free, because Google, Mozilla and Apple relay them at no charge. What you pay for, if you pay, is the software that stores subscribers, manages the sending queue and gives you a dashboard.
Do push notifications work on iPhones?
Only for sites a visitor has added to their home screen. Apple decides this, and almost no one installs sites that way, so treat iOS as close to zero.
Do I need an app to use web push?
No. Web push runs in the browser. It needs a service worker, an HTTPS site and the visitor’s permission.
Is web push secure?
Payloads are encrypted end to end between your server and the visitor’s browser, and your server proves who it is with a VAPID key. The push services relay messages but can’t read them.