How Chrome notifications behave on a Mac and where to change them

A notification arrives on the Mac. It says Google Chrome, it has the Chrome logo, and the message underneath came from a news site that was visited once in March. Somewhere else in the same browser, a calendar page is quietly failing to alert anyone about a meeting in ten minutes. Both of those facts come from the same place, and turning the obvious switch off makes the second problem worse.

The reason is that a Chrome notification on macOS has to clear two separate permission systems that were designed by different companies and do not know much about each other. Changing the wrong one produces either no effect or too much effect. What follows is where each control actually lives, what it governs, and where the layered design runs out of answers.

A notification has to clear two gates, not one

The first gate is the site asking Chrome. When a page calls the Notifications API, Chrome decides whether that origin is allowed, based on the permission the reader granted or denied at some point in the past, or on the site settings default.

The second gate is Chrome asking macOS. Starting in Chrome 59, Chrome stopped drawing its own notification popups on macOS. Google's developer blog states that from that version, notifications sent through the Notifications API or the chrome.notifications extensions API are shown directly by the macOS native notification system instead of Chrome's own system, and that the change fixed long standing bugs such as Chrome not respecting the system Do Not Disturb setting.

That second sentence is the useful one. Chrome on macOS is now a well behaved notification client of the operating system, which means macOS can silence it completely, and does, without telling Chrome anything.

So a notification that never appears has three plausible causes and they need to be checked in a fixed order. macOS is blocking Chrome as an application. Chrome is blocking the site. Or the site was never asked in the first place. Checking them out of order wastes time, because the site level permission can read as granted while the operating system throws the result away.

The same layering explains the opposite complaint. A site that was allowed two years ago keeps its permission until something removes it, and macOS will keep displaying whatever Chrome hands over, because as far as macOS is concerned the sender is Chrome and Chrome was allowed.

What macOS decides about Chrome

Open System Settings, click Notifications in the sidebar, and select Google Chrome in the application list. Apple's Mac User Guide lists the per application controls, and each one answers a different question.

Allow notifications is the master switch for the application. With it off, nothing Chrome sends reaches the screen, regardless of what any website was permitted to do.

The alert style decides how long a notification stays. Apple describes the two shapes plainly: temporary notifications disappear after a while, and persistent notifications remain until they are dismissed. For a browser holding a calendar or an on call dashboard, persistent is usually the right answer and is almost never the default.

The rest of the list covers the details people actually notice. Show previews takes Always, When Unlocked or Never, and Always includes the login window. Badge application icon controls the count on the Dock icon. Play sound for notification controls whether anything is audible. Allow time sensitive alerts lets through notifications marked as needing immediate attention. Notification grouping takes Automatic, By Application or Off, which determines whether twenty items from Chrome stack into one row in Notification Center or list separately.

Above the application list sit three settings that override everything below them. Apple's guide describes controls for whether notifications show when the display is sleeping, when the screen is locked, and when mirroring or sharing the display. The last of those defaults to turning notifications off during screen sharing, which is the correct default and also the reason notifications seem to vanish for the length of a call.

What Chrome decides about sites

Chrome's own controls sit at Settings, then Privacy and security, then Site Settings, then Notifications. Google's help page describes the default behaviour options there, including letting sites ask to send notifications and a quieter messaging option that suppresses the permission prompt and shows a bell icon in the address bar instead.

Two details on that page matter more than the main toggle.

The first is the block list. Under the heading for sites that are not allowed to send notifications, a site can be added by address without ever visiting it again. This is the surgical tool. Blocking one origin leaves every other permission intact, which the macOS level switch cannot do.

The second is automatic revocation. Google's help states that Chrome may remove notification permissions from sites that have not been visited recently, and that Safety Check under Privacy and security will report permissions removed for a number of sites, with an option to restore them. This is worth knowing before spending an afternoon on a site that used to work. Nothing broke. The permission expired through disuse, and re-granting it takes one visit.

Checking a single site quickly

Click the icon at the left of the address bar while on the site in question. The permission state for notifications shows there, and it can be changed without opening Settings. If the row is missing entirely, the site has never asked, which usually means the page needs to be signed in or the in page notification setting needs to be switched on before the browser prompt will fire at all.

Everything arrives as Google Chrome, and that is the real ceiling

The two gates can both be configured correctly and the result can still be unsatisfying, because of one design fact.

Google's post on the move to native notifications states that the Chrome logo will always be displayed and cannot be replaced or altered. On macOS, that is not only a branding note. It means the operating system sees one sender. A work calendar, a company chat tool, a support desk and a forum that was allowed by accident are all, to macOS, the same application.

The consequences follow directly.

The question	What Chrome can do	What macOS can do
Silence one site, keep the rest	Yes, per origin in Site Settings	No, only the whole browser
Give one site a persistent alert and the rest a banner	No	No, the style is per application
Show how many unread items one service has	No, the Dock badge is one number for the browser	No
Let one service through during a Focus	No	No, Focus allows or blocks Chrome entirely
Keep two accounts on the same service separate	Profiles separate the sessions	No, both still report as Google Chrome

The bottom row is where most of the frustration actually sits. Two Chrome profiles, one personal and one for work, keep their cookies and sessions apart correctly. Their notifications do not stay apart. Both profiles send from the same application identity, so there is no way to tell macOS to allow the work profile during a Focus and hold the personal one.

Focus makes the all or nothing shape obvious

Focus on a Mac is turned on from Control Center and can be set for a duration, such as for one hour, or until the end of a calendar event. Apple's guide also notes that if Focus is kept up to date across Apple devices, turning one on or off on the Mac does the same on the other devices.

Focus settings include an Allowed Apps list. That list is the mechanism for letting something through while everything else is held, and it is where the single sender problem becomes concrete. Adding Chrome to Allowed Apps lets the meeting reminder through. It also lets through the deals site, the forum and anything else with a live permission, because all of them are Chrome.

The workaround people reach for is to prune permissions hard, allowing only a handful of origins so that allowing Chrome is close enough to allowing those origins. That works, and it is a reasonable thing to do once a year. It does not survive the next time a site is granted permission in a hurry.

When the fix is not a setting

At a certain point the honest reading is that the notification problem is a container problem. One application holding twelve services can only ever have one notification identity, and no amount of configuration inside it changes that.

macOS ships with a partial answer. From macOS Sonoma 14 onward, Safari can save any page as a web app through File and then Add to Dock. Apple states that a web app functions independently of Safari and shares no browsing history, cookies, website data or settings with it, that the Dock icon can show the number of unread notifications, and that it can be added as a login item so it opens at login. Each one is saved to the Applications folder of the home folder. Crucially, each web app appears on its own in System Settings, so one service can be persistent and audible while another is silent.

The cost is visible immediately. A web app has a stripped toolbar with a back button, a forward button, a Share button and buttons for installed Safari extensions. There are no tabs, no bookmarks, and nothing that groups the web apps together. Five services means five Dock icons and five separate sets of notification settings to maintain, which is manageable at two and tiresome at eight.

The same idea at a larger scale is what an app aggregation browser does. Each service gets its own window and its own session, so the alert for a chat tool and the alert for a calendar are separate senders that can be silenced, badged and allowed through a Focus independently, while still being organised in one place rather than scattered across the Dock. The way separate sessions per service are arranged is set out in Workspaces, and which services are supported in that shape is listed in Supported apps.

What to change first

Start at the operating system, not in Chrome. Open System Settings, then Notifications, then Google Chrome, and set the alert style to persistent and turn on the badge, so that anything genuinely arriving becomes visible rather than flashing past. Then open Site Settings in Chrome and block the two or three origins that are responsible for most of the noise, by address, without touching the rest. If the result is still one undifferentiated stream of Chrome alerts that cannot be separated during a meeting, the setting has been found and it is not enough, and the next step is to give the services that matter their own identity, which is what SpaceDeck is built to do.