 Rob Kochman [X](https://twitter.com/rkochman)
Published: January 6, 2026
Beginning this month, Chrome will start rolling out Push API message rate limits
for sites that send many notifications without much site engagement. This post
explains the change, and the sites likely to be impacted by it.
The open web is a powerful platform for connecting with users, and the [Push
API](https://developer.mozilla.org/docs/Web/API/Push_API) has been a
transformative part of that. In conjunction with the [Notifications
API](https://developer.mozilla.org/docs/Web/API/Notifications_API), the
Push API enables sites to deliver timely notifications even when the website is
not running in the browser. This allows for a persistent and valuable connection
between users and the sites they care about most.
However, as is often the case with powerful technology, there's a potential for
misuse. Many of us have experienced it: a website that bombards us with a
constant stream of notifications that aren't relevant or valuable. This can be
due to issues such as a website changing its behavior since the permission was
granted or a user getting tricked into accepting a permission request. Such
unwanted notifications disrupt a user's workflow and can lead to a negative
perception of notifications and the web altogether. We believe that the power of
push notifications should be matched with a responsibility to use them wisely.
## Our ongoing commitment to a better notification experience
We've worked hard to give users more control and to tackle notification spam
head-on. In Chrome 80, we introduced [quieter notification permission
prompts](https://blog.chromium.org/2020/01/introducing-quieter-permission-ui-for.html),
which shows a more subtle prompt for sites with low acceptance rates or for
users who frequently block notification requests. More recently, for Chrome on
Android, we've begun to use [on-device machine
learning](https://blog.chromium.org/2025/05/fighting-unwanted-notifications-with.html)
to identify and warn users about potentially spammy or malicious notifications,
which helps protect users from phishing attempts and other harmful content
without compromising privacy. We also [automatically revoke notification
permissions](https://blog.google/products/chrome/google-chrome-safety-update-september-2024/)
from sites that Google Safe Browsing identifies as engaging in abusive behavior.
Lastly, in October we announced that Chrome will automatically [remove
notification permission on a per-user
basis](https://blog.chromium.org/2025/10/automatic-notification-permission.html)
for sites a user hasn't interacted with recently. These are just a few examples
of our ongoing commitment to creating a safer and more pleasant notification
experience for everyone.
## A new layer: Push API rate limits
To further protect Chrome users from overwhelming notification volume and to
ensure that notifications remain a useful tool for everyone, we'll be
introducing a rate limiting mechanism for the Push API based on user engagement.
Our goal is to create a better web, where users are in control and developers
are empowered to build meaningful connections. This change is designed to curb
abusive notification practices while having no impact on legitimate websites.
### How it works
Initially, our determination for rate-limiting a site will be based on three key
factors, which are calculated daily:
- The number of push messages a site has sent per time spent on a site.
- The number of permission prompts shown per time spent on the site.
- The level of engagement that user has with the site (based on the site engagement score and number of foreground minutes).
When a site is identified as sending a high volume of notifications with very
little user engagement, we will consider it disruptive and will limit its
ability to send messages to a value no less than 1000 per minute. Requests above
that limit will result in an HTTP 429 response.
To prevent disruptive sites from quickly cycling between disruptive and
non-disruptive behavior, the logic to remove the rate-limit is more complex:
- After the first day of disruptive behavior, the rate limit will apply for one day.
- After the second day of disruptive behavior, the rate limit will apply for seven days.
- After the third and subsequent day of disruptive behavior, the rate limit will apply for 14 days.
- The count will reset after 42 consecutive days of non-disruptive behavior.
Though this describes our initial approach, the specifics of this calculation
may evolve over time as the ecosystem evolves, to best serve both users and the
developer community.
### Will this impact my site?
It's important to emphasize that this change will only affect the Push API.
Sites will still be able to send notifications while open using the
Notifications API.
Nearly all websites will be unaffected by this change. This initiative is
targeted at a small number of sites that are sending an excessive number of
low-value notifications. For the broader developer community that is focused on
sending timely, relevant, and engaging notifications, this change will help to
preserve the integrity and effectiveness of this powerful communication channel.
We believe this is a necessary step to ensure a healthy and sustainable future
for web notifications. By encouraging a more thoughtful and user-centric
approach, we can collectively create a better notification experience for
everyone on the web.