Safari Notifications: How to Enable, Turn Off, and Send Web Push

Safari notifications work differently on iPhone and Mac. On Mac, websites can send notifications that still arrive after Safari is closed. On iPhone and iPad, Web Push is available on iOS/iPadOS 16.4 or later, but the website first has to be added to the Home Screen as a web app.

If you are here to send Safari notifications from your own website rather than manage notifications you receive, jump to how to send Safari Push with EngageLab WebPush .

How Safari Notifications Work on iPhone and Mac

Safari notifications are website push notifications delivered through Apple's notification system. They can show up alongside app notifications, which is why they feel more native than an alert that only appears inside a browser tab.

The setup changes depending on the device. Apple added Web Push for Home Screen web apps on iPhone and iPad in iOS/iPadOS 16.4. A website cannot simply start sending alerts from an ordinary Safari tab: the user adds it to the Home Screen, opens the web app, and grants notification permission after an interaction.

For businesses, Safari becomes part of a broader cross-browser Web Push delivery strategy. A campaign may need to reach Safari users on Apple devices and Chrome, Firefox, or Edge users elsewhere, while each browser keeps its own permission, display, and delivery rules.

How to Turn Safari Notifications On or Off

How to Turn On Safari Notifications on iPhone

On iPhone, a supported website has to be used as a Home Screen web app before it can send Web Push notifications.

1. Open the website in Safari.
2. Tap Share , then choose Add to Home Screen .
3. Open the new web app from your Home Screen.
4. Use the site's notification or subscribe control.
5. When iOS displays the native permission prompt, tap Allow .

Apple requires notification permission to follow a user interaction. A site cannot silently grant itself permission or force the native notification prompt in the background.

How to Turn Off Safari Notifications on iPhone

Once a website has been installed as a web app, its notification controls behave much like those of a regular app:

• Open Settings > Notifications .
• Find the web app.
• Switch Allow Notifications off.

Deleting the web app from the Home Screen also removes that installed web app from the device.

How to Manage Safari Notifications on Mac

If one website is sending too many notifications, you do not need to silence every website in Safari.

• Open Safari > Settings > Websites > Notifications .
• Find the website you want to manage.
• Set it to Deny or remove its permission.

You can also stop websites from asking for permission by turning off Allow websites to ask for permission to send notifications in the same panel.

To silence website notifications at the macOS level, open System Settings > Notifications , select the relevant website or Safari notification entry shown by your version of macOS, and turn notifications off.

If strange Safari notifications are warning you about viruses, prizes, or urgent security problems, avoid clicking them. Check Safari > Settings > Websites > Notifications first and remove any site you do not recognize.

Safari Notifications on iPhone: What Websites Need to Support

For a user, enabling notifications is only a few taps. The website behind that button has more work to do.

A typical iOS Web Push setup needs:

• HTTPS: Web Push permission and service workers require a secure website.
• A service worker: It handles push events while the page is not active.
• Push and Notifications APIs: These connect the browser subscription to notification delivery.
• A Home Screen web app on iOS/iPadOS: Safari Web Push on iPhone and iPad works through web apps added to the Home Screen.
• A user-triggered permission request: The notification prompt should follow an intentional action such as tapping a subscribe button.

This last point matters beyond implementation. Asking for notification permission the moment someone lands on a page gives them very little reason to say yes. If they deny the browser's native permission request, recovering that subscriber usually requires them to change browser or system settings manually.

That makes permission strategy part of subscriber growth, not just SDK setup. EngageLab's Web Push permission and subscriber management gives teams a way to control how the subscription request appears before launching the browser's native permission dialog.

If you are building a PWA, see our PWA Push implementation guide for the broader setup.

How Safari Web Push Works for Businesses

One detail causes a lot of confusion here: today's Safari Web Push is not the same implementation that older Safari versions used.

Modern Safari supports the standards-based Web Push stack. In EngageLab WebPush, Safari 16+ users can use the W3C Push API. Existing subscribers that were created through Safari's older push method can continue on that path, while new Safari 16+ subscribers are prioritized for W3C Web Push.

Safari 15 and earlier are the legacy case. Those versions can require a Safari Push certificate. EngageLab keeps legacy certificate support for businesses that still need to reach that audience, with shared certificate support available when a custom certificate is not supplied.

This distinction matters when you are evaluating a Web Push provider. Maintaining browser-specific delivery logic, old Safari certificate handling, subscriber state, targeting, and reporting quickly becomes more work than creating the notification itself.

How to Send Safari Push Notifications with EngageLab WebPush

EngageLab WebPush for cross-browser notification delivery gives product and marketing teams one workflow for Safari, Chrome, Firefox, Edge, and other supported browsers. You can manage website integration, subscriber permissions, campaign creation, targeting, scheduling, and reporting without building separate campaign tooling for each browser.

1. Add Your Website Domain

In EngageLab WebPush, start with App Settings > Integration Settings and add the HTTPS website domains that will send notifications.

Keep the Service Worker scope in mind during integration. The default root-level setup gives the worker the broadest useful scope. If your site already has a PWA Service Worker, plan the integration so the workers do not compete for the same scope.

2. Integrate the WebPush SDK

The Web SDK handles subscriber registration and the browser-specific delivery path. For Safari 16+, EngageLab can prioritize W3C Web Push for new subscribers while retaining support for older Safari subscribers where needed.

That keeps browser compatibility inside the EngageLab cross-browser Web Push infrastructure instead of forcing your team to maintain separate campaign systems for Safari and other browsers.

3. Improve Opt-ins with EngageLab Guided Request

EngageLab supports direct, guided, and custom permission requests. For most consumer-facing sites, the Guided Request is a useful starting point because it gives the visitor context before the browser asks for a permanent permission decision.

The guided prompt appears before the native permission dialog. You can explain what the subscriber will receive and trigger the browser prompt only after the visitor shows interest.

Configure it under WebPush > Basic Settings > Notification Authorization Configuration . Guided prompts can support multiple languages and message categories, helping users understand what they are subscribing to before the native request appears.

4. Create and Send the Safari Push

Once subscribers are registered, create the notification under Push > Create Push . Set the title, notification content, target audience, click destination, and send time before previewing the message.

Safari has its own presentation limits. Rich images and action-button behavior are not identical across Chrome, Firefox, Edge, and Safari, so build the message around the title, body, icon, and landing destination rather than assuming every browser will render the same creative.

5. Personalize Send Time with EngageLab Intelligent Delivery

A fixed campaign time is simple, but it becomes less useful when subscribers live in different time zones or browse your site at very different hours.

EngageLab's intelligent Web Push delivery can use a subscriber's historical activity and device time zone to choose a more appropriate delivery time for that user. For subscribers without enough activity history, you can define a fallback: send immediately or use a specified time in the user's local time zone.

This is most useful for non-urgent campaigns such as content updates, promotions, re-engagement, and recurring offers. Order status, account security, and other time-sensitive notifications should still be sent when the event happens.

How to Optimize Safari Web Push with EngageLab

Getting the integration live is the first milestone. The next questions are more useful: how many visitors subscribe, how reliably messages arrive, when they are sent, and what users do after they receive them.

Grow Web Push Subscribers Before the Native Prompt

Ask for permission when there is an obvious reason to subscribe. A reader following a topic, a shopper tracking a price, or a customer waiting for an order update already understands why another notification could be useful.

That gives you a simple permission sequence:

1. Let the visitor reach a relevant moment in the journey.
2. Explain the notification they can receive.
3. Use the guided prompt to confirm interest.
4. Trigger the native browser permission request.

On iPhone and iPad, also make the Home Screen requirement obvious. A visitor cannot subscribe to iOS Web Push from a normal Safari tab alone; they need to add the site to the Home Screen and open it there first.

Measure Safari Web Push Performance in EngageLab

EngageLab WebPush follows the push lifecycle from the selected audience through sending and delivery, then into impressions and clicks where the browser channel can report them. Its Web Push analytics and performance tools also let you compare results by browser instead of treating every channel as if it reports data in the same way.

Safari needs one extra note. Messages delivered through Safari's system channel cannot return the same impression and click callbacks available on some other Web Push channels. A low or zero Safari impression count can therefore reflect the reporting path rather than a failed notification.

Check Safari separately when you compare browser performance. Use EngageLab delivery data to diagnose the push pipeline, then connect the notification's landing URL to your own web analytics when the business outcome is a purchase, signup, article read, booking, or another on-site action.

Run Smart A/B Tests with EngageLab WebPush

EngageLab WebPush includes Smart A/B Testing for Web Push campaigns . Keep the audience and offer stable, then test one meaningful variable at a time, such as the notification title, content, send time, or click destination.

After the test is sent, compare delivery and click performance between groups. Delivery rate and CTR tell you whether the push reached people and earned attention; they do not automatically tell you whether the campaign produced more purchases, registrations, or another downstream conversion.

For commercial campaigns, define that final business action before the test and measure it in your website or analytics stack. That keeps the winning variant tied to the result the campaign was actually meant to produce.

The Bottom Line

If you only want to control Safari notifications on your own device, the relevant settings are close at hand: manage individual websites in Safari on Mac, or manage the installed web app under Notifications on iPhone.

For businesses, Safari belongs inside the wider Web Push workflow. Modern Safari supports standards-based Web Push, older Safari versions still create a legacy compatibility case, and iPhone adds its Home Screen requirement. EngageLab brings those browser paths together with subscriber permission management, intelligent delivery, campaign creation, A/B testing, and performance reporting.

The practical goal is simple: get the subscription at the right moment, send when the notification is useful, and measure the action you actually wanted the user to take. If you want to manage that workflow across Safari, Chrome, Firefox, and Edge from one place, explore EngageLab WebPush for cross-browser notification delivery before setting up your first campaign.