Web Push Notifications for Websites: A Practical Guide

By Kanishak Sharma, Adflipr

Web push reaches visitors through their browser, no email or app needed.

Web push notifications, also called browser push notifications or push notifications for websites, are short, clickable messages a website sends to a visitor's browser, which show up on their screen even when your site isn't open. The visitor opts in with one click on a browser prompt, and you don't need their email address, their phone number or an app. That's what makes web push useful: it reaches the people who browse your site but never fill in a form.

It also makes web push easy to get wrong. Browsers control the permission prompt, they punish sites that ask too early, and once a visitor clicks "Block" you can't ask again. This guide covers how web push works, which browsers support it, when to ask for permission, what to send, and the mistakes that get notifications blocked.

This guide is published by Adflipr, a marketing automation platform that runs email, WhatsApp and web push from one contact list. The rules and use cases below apply to any business with a website, whichever tool you use.

What Are Web Push Notifications?

Web push notifications are messages sent from a website's server, through the visitor's browser, to their device, where they appear as a system notification with a title, a short text, an icon and a link. They're built on web standards (the Push API, the Notifications API and service workers), so any site can use them without building an app.

Key definitions:

• A push message is the data your server sends. It travels through a push service run by the visitor's browser vendor, not directly to the device.
• A notification is what the visitor sees: the small box on their screen. Browsers require every push message to show one, so silent pushes aren't allowed.
• A service worker is a small script your site installs in the browser. It receives push messages and shows the notification, even when your site isn't open in a tab.
• A subscriber is a browser that granted permission. Permission belongs to that browser on that device, so one person on a laptop and a phone counts as two subscribers.

How Do Web Push Notifications Work?

Web push works in four steps: the visitor grants permission, the browser creates a subscription, your server sends a message to the browser's push service, and the service worker shows it as a notification (web.dev, push notifications overview).

Four steps from permission to notification.

1. Permission. Your site asks for permission after the visitor does something, such as clicking a "Notify me" button. The browser then shows its own prompt: Allow or Block.
2. Subscription. If the visitor allows it, the browser contacts its push service and returns a subscription: a unique address for that browser, plus encryption keys. Your server stores it.
3. Sending. To send a notification, your server encrypts the message and sends it to the push service at that address. The push service is chosen by the browser vendor; you don't pick it.
4. Display. The push service delivers the message when the device is online. If it's offline, the message is queued until it comes back or the message expires. The service worker then shows the notification, and a click opens the link you set.

The sender can set how long a message stays valid, so a flash-sale reminder can expire instead of arriving the next morning.

What Do You Need to Use Web Push?

To use web push you need a website served over HTTPS, a service worker on that site, a way to ask for permission, and a tool or server that sends the messages. Most businesses get the last three from a push or marketing automation tool, so in practice the only hard requirement on your side is HTTPS.

• HTTPS. Service workers only run in secure contexts, meaning pages served over HTTPS (MDN, Service Worker API). A site still on plain HTTP can't use web push at all.
• A service worker. The small script that receives messages and shows notifications. Push tools usually give you one to add, or add it for you through a plugin or app.
• A permission ask. Your own button or message, followed by the browser's prompt (more on timing below).
• A sending tool. Something that stores subscriptions, encrypts messages and sends them to each browser's push service.
• An off switch. A visible way for subscribers to turn notifications off on your site, so they don't reach for the browser's Block setting instead.

Which Browsers Support Web Push?

Web push works in the major desktop browsers and in browsers on Android. On iPhone and iPad it only works for sites the user has added to their Home Screen as a web app, not for sites opened in Safari.

Browser and device	Web push support	Notes
Chrome, desktop and Android	Yes	Shows a quieter prompt on sites where most visitors block notifications
Microsoft Edge, desktop	Yes	Every push message must show a notification
Firefox, desktop	Yes	Shows the prompt only after the visitor clicks or taps something (since Firefox 72)
Safari on Mac	Yes, since Safari 16 on macOS Ventura	Needs a user gesture before asking
Safari and other browsers on iPhone and iPad	Only for Home Screen web apps, since iOS and iPadOS 16.4	Not available to a site opened in the browser

Sources: Chromium blog, Microsoft Edge docs, Mozilla, WebKit, Meet Web Push, WebKit, Web Push for iOS and iPadOS.

What this means in practice: browser push is strongest with desktop visitors and Android visitors. If most of your traffic is iPhone users browsing in Safari, plan on email or WhatsApp for them, and treat web push as the channel for everyone else.

Web Push vs Email vs App Push

Web push, email and app push differ in what you need from the customer: web push needs only a click on a browser prompt, email needs an address, and app push needs an installed app. Each is good at a different job.

	Web push	Email	App push
What the customer gives you	A click on "Allow"	Their email address	An app install, then "Allow"
Who you can reach	Visitors who never shared contact details	Anyone with an address on your list	Only people who installed your app
Message length	A title and a line or two	As long as you need	A title and a line or two
Tied to	One browser on one device	The person, on any device	One app on one device
Best for	Quick, time-sensitive nudges back to your site	Receipts, newsletters, detailed offers	Businesses that already have an app

The two channels work best together. A visitor who allowed push but never gave an email address can still be reached. A customer on your email list can get the receipt by email and the "your item is back" nudge by push.

When Should You Ask for Push Permission?

Ask for push permission at a moment when the benefit is obvious to the visitor, never as soon as they land on your site. web.dev's guidance on permission UX calls the on-load prompt the worst thing you can do: the visitor has no idea why you're asking, the prompt gets in their way, and many will click Block (web.dev, permission UX).

Ask when the benefit is obvious, never on page load.

Browsers back this up:

• Firefox only shows the prompt after the visitor has clicked or tapped something on the page. Prompts fired on page load are reduced to a small icon in the address bar. In Mozilla's study, prompts shown after a user interaction were accepted far more often than prompts on load.
• Chrome switches to a quieter permission prompt for users who usually block notifications and for sites with very low acceptance rates. Ask badly and your prompt gets quieter for everyone.
• Safari requires an explicit user gesture before a site can request a push subscription.
• Lighthouse, Google's site audit built into Chrome DevTools, flags any page that requests notification permission on page load, and the failed check counts against the page's Best Practices score (Chrome for Developers).

Dismissed vs blocked

Closing the prompt and blocking it are different outcomes. If the visitor dismisses the prompt without choosing, the permission stays undecided: the browser treats it as a no for now, but your site can ask again later (MDN, Notification.permission). If they click Block, it's close to permanent. Your site can't ask again; the visitor has to find the setting in their browser and change it themselves, which few people do.

The two-step ask

The pattern that works is to ask in your own words first, then show the browser prompt only to people who said yes:

1. Show your own small message or button at a relevant moment: "Want a notification when this is back in stock?"
2. If they click yes, trigger the browser's real prompt. They already know why it's coming, so they're likely to allow it.
3. If they click no, hide your message and don't ask again for a while. The browser prompt was never shown, so you can still ask later.

When to ask, and when not to:

Moment	Ask?	Why
Visitor clicks "Notify me when it's back" on an out-of-stock product	Yes	A click, and an obvious reason to say yes
Customer finishes an order and is offered shipping updates	Yes	Specific, short-term value
Visitor books an appointment and is offered a reminder	Yes	They know exactly what they'll get
Reader clicks "Get new posts" after reading a few articles	Yes	Clear intent from a regular reader
Visitor lands on the homepage	No	No click, no context; browsers restrict it and Lighthouse flags it
Visitor already said no to your own message	Not yet	Wait a while before asking again

Add a permanent toggle too, for example in the footer or the account page, so regular visitors can turn notifications on or off themselves.

What Can Businesses Use Web Push For?

Businesses use web push for short, timely messages that bring someone back to a specific page: an item they wanted, an update they asked for, or something about to expire. The best uses are the ones the visitor would be glad to receive.

Online stores

• Cart reminders for shoppers who added items and left, with a link straight back to the cart.
• Price-drop alerts on a product someone viewed or saved.
• Back-in-stock alerts for visitors who asked to be told.
• Order and delivery updates, if the customer opted in after checkout.

Service and booking businesses

• Appointment reminders the day before, with a link to reschedule.
• Slot availability, for example a class or table that just opened up.

Content and community sites

• New articles or episodes for readers who subscribed.
• Updates on a story or event they're following.

Any business

• Time-limited offers, sent rarely and only to people likely to care.
• Reminders to finish something: a form, a signup or a quote request left halfway.

How Do You Write a Good Push Notification?

A good push notification says one thing, in a few words, and links to exactly the page it talks about. The visitor sees it for a few seconds between other tasks, so there's no room for a second idea.

• Lead with the specific thing. "The Blue Linen Shirt is back in your size" beats "New arrivals are here!"
• Keep it short. A title and one line. Browsers and operating systems cut off long text, and the cut-off point differs between them.
• Link to the exact page. The product, the cart, the booking. Not your homepage.
• Use an image when it helps. A product photo makes a price drop instantly recognisable.
• Make urgency real. "Sale ends at midnight" is fine if it does. Fake countdowns teach people to ignore you.
• Mind the clock. A notification at 2 a.m. in the subscriber's time zone is a fast way to get blocked.
• Send less than you think. Every notification interrupts someone. A few useful ones a week beat a daily stream.

Web Push Message Examples You Can Adapt

Cart reminder

You left something behind Your cart is saved: 2 items, ready when you are.

Price drop

Price drop on the Trail Runner 2 Now $89, down from $110. The size you viewed is in stock.

Back in stock

It's back: Ceramic Pour-Over Set You asked us to tell you. Limited stock this time.

Appointment reminder

See you tomorrow at 10:30 Haircut with Priya. Tap to reschedule if plans changed.

New content

New guide: Planning a 3-day trip to Jaipur The one you asked for, with a printable checklist.

Each one names a specific thing, says why it matters to this person, and links to one page.

Common Web Push Mistakes

• Asking on page load. The most common mistake and the most expensive: blocked visitors are hard to win back, and Chrome may quieten your prompt for everyone.
• Faking the browser prompt. A custom message that imitates the browser's own dialog breaks visitors' trust, and Mozilla warns that spoofed browser UI will meet stronger enforcement.
• Sending the same message to everyone. A discount push to someone who bought yesterday is noise. Use what you know about the visitor.
• Linking to the homepage. The visitor clicked for a specific thing; make them hunt for it and they leave.
• Too many notifications. If people start blocking or ignoring you, the first fix is usually sending fewer.
• No way to opt out on your site. If the only off switch is the browser's Block setting, that's what people use.
• Expecting it to reach every iPhone visitor. On iPhone and iPad, web push only works for Home Screen web apps.
• Duplicating every email as a push. Pick one channel for each moment, and use the other only as a fallback.

How Do You Measure Web Push?

Measure web push by how many visitors subscribe, how many notifications are delivered and clicked, and what happens after the click. Track it per message, not just in total, so you can see which messages earn their place.

• Opt-in rate: subscribers divided by visitors who saw your ask. If it's low, look at where and when you ask, not the wording alone.
• Delivered: messages the push services accepted and passed on. Subscribers who cleared their browser data or switched devices drop out over time.
• Clicks and click rate: the clearest signal of whether a message was wanted.
• Unsubscribes and blocks: a jump after one message tells you something about that message or its timing.
• Results after the click: orders, bookings, signups or pages read from push visits.

How Adflipr Handles Web Push

Adflipr is a marketing automation platform for online stores that runs email, WhatsApp and web push from one contact list and one automation builder. Adflipr's push is browser push: notifications go to your subscribers' web browsers, and there's no app to build or install.

• One-click browser opt-in. Visitors subscribe with a single click on the browser prompt; no email address needed.
• Push inside the same automations as email. A push notification is a step in Adflipr's automation builder, alongside email, with delays, triggers and split conditions.
• Abandoned cart push. Shoppers who leave items behind can get a push notification about their cart.
• Price-drop alerts. Shoppers can be notified when a product's price drops.
• Click and delivery data. See how many notifications were delivered and clicked.

Adflipr connects to Shopify and WooCommerce stores. More detail on Adflipr's web push notifications and the automation builder, or read our guide to WhatsApp marketing and our overview, What Is Adflipr?

Try Adflipr free and add push to the automations you already run.

Key Takeaways

• Web push reaches visitors through their browser with one click of permission, no email, phone number or app needed.
• Your site must be on HTTPS; service workers don't run on plain HTTP.
• It works in Chrome, Edge, Firefox and Safari on Mac, and on Android; on iPhone and iPad only for Home Screen web apps.
• Never ask for permission on page load. Ask at a moment of clear value, in your own words first, then show the browser prompt.
• A "Block" is close to permanent, and low acceptance rates can make Chrome quieten your prompt.
• Keep each notification to one specific thing, linked to one page, and send fewer than you think.
• Use web push alongside email: each channel for the moment it suits best.

Frequently Asked Questions

What is a web push notification?

A web push notification is a short, clickable message a website sends to a visitor's browser, which appears on their screen even when the site isn't open. The visitor opts in through a browser prompt, without sharing an email address or phone number.

Do web push notifications need an app?

No. Web push works through the browser, using a small script called a service worker that the site installs. App push is a different channel that only reaches people who installed your app.

Do web push notifications need HTTPS?

Yes. Web push depends on a service worker, and browsers only run service workers on pages served over HTTPS. A site on plain HTTP can't send web push notifications.

Do web push notifications work on iPhone?

Only for sites the user has added to their Home Screen as a web app (often called a PWA, progressive web app), since iOS and iPadOS 16.4. A site opened in Safari or another browser on iPhone can't send web push.

How do I add push notifications to my website?

Serve your site over HTTPS, add the service worker your push tool provides, put a clear opt-in button or message on the pages where push is useful, and connect a tool that stores subscriptions and sends the messages. Then ask for permission only after the visitor shows interest, never on page load.

When should a website ask for notification permission?

At a moment when the benefit is clear, for example on an out-of-stock product page or after an order, and after the visitor has clicked something. Asking as soon as someone lands on the site leads to blocks, and browsers like Firefox and Chrome restrict or quieten those prompts.

Can I ask again after a visitor blocks notifications?

No. Once a visitor blocks notifications, the site can't show the prompt again. The visitor has to change the setting in their browser, so it's worth asking in your own words first and showing the browser prompt only to people who said yes. If they only closed the prompt without choosing, you can ask again later.

How often should I send web push notifications?

There's no official limit. Send only when you have something specific and useful for that subscriber, and watch blocks and unsubscribes after each message. If they rise, send less.

Are web push notifications better than email?

They do different jobs. Web push is best for quick, timely nudges to visitors who may never have given you an email address; email is better for longer content, receipts and anything people want to keep. Most businesses get the most from using both.

Sources

web.dev, Push notifications overview and Permission UX, Chromium blog, Introducing quieter permission UI for notifications, Mozilla, Restricting notification permission prompts in Firefox, WebKit, Meet Web Push and Web Push for Web Apps on iOS and iPadOS, Microsoft Edge, Re-engage users with push messages, MDN, Service Worker API and Notification.permission, Chrome for Developers, Lighthouse notification audit. All read October 7, 2026.

---

About the author: Kanishak Sharma writes Adflipr's guides on email marketing, marketing automation and customer messaging. More from Kanishak on his Adflipr author page and LinkedIn.