Published: October 16, 2026
Chrome has completed deprecating the unload event as of Chrome 155. Going forward, by default, unload handlers no longer fire for Chrome and other Chromium-based browsers. This was a years-long effort to remove an API that is increasingly unreliable and shouldn't be depended on by websites and web developers.
Background
The unload event was designed when most web pages were opened, consumed, and then closed. As the page was closed, the unload event let code complete tasks such as saving user data, cleaning up resources no longer required, or beaconing analytics.
While this sounds sensible, the page lifecycle today doesn't follow such a straightforward and predictable path. Many pages are left open for a long time, and many more are closed without having the opportunity to run unload handlers. This is particularly true on mobile when backgrounded pages are frequently silently closed by the operating system to manage limited mobile resources. It was less true on desktop where unload was mostly reliable (at least for Chrome and Firefox).
The bfcache introduced another complication. Pages using bfcache are held by the browser in memory for a period of time so if the user goes back, the page can be instantly restored rather than reloaded from scratch. Since unload is expected to be fired at the end of the page lifecycle, without the expectation of the page being restored, using unload and bfcache together is likely to cause breakage. Different browsers handled this differently with some prioritizing bfcache (especially on mobile where unload often didn't run anyway) and others unload (especially on desktop). Confusingly, all browsers did still fire unload if the bfcache was not used so it appeared to work some of the time, but inconsistently.
All in all it was confusing, unreliable, and difficult for websites to understand and have certainty over.
Deprecation over more unreliability
For years Chrome has talked about deprecating unload to remove this uncertainty as well as unlock more bfcache navigation to benefit users. However, this would be a breaking change to current use of the web and would require careful consideration to reduce any impact.
The Chrome team felt that it was worth the substantial effort to resolve this and have now completed this effort for all our users. It is our opinion that developers shouldn't be using this event given its unreliability and we decided to make a definitive decision here to deprecate it fully in Chrome, rather than continue with the status quo. Given its potential for breaking existing sites, we took a careful staggered rollout to this deprecation, from March 2025 until September 2026, while monitoring for breakages and listening to feedback from sites and web developers.
This has now completed and the unload event consistently no longer fires on Chrome, even when it can (though see the next section for opt-outs to the deprecation).
Now that Chrome has completed this task for the billions of Chrome users, we hope other browsers will feel comfortable to follow suit so we can consider this legacy API retired from the web platform, excluding a small number of opt-outs. We will be continuing the discussion in this HTML specification issue. This deprecation will shortly be enabled by default in the Chromium codebase meaning other Chromium-based browsers will get this change too, unless they decide to change this default.
Opt-outs
Chrome has offered opt-outs to this behaviour change through the Permission Policy API, and Chrome Enterprise settings. A small number of websites have implemented these opt-outs and so continue to receive unload events on their sites from Chrome users, in the same unreliable manner as previous.
We have no plans to remove these opt-outs, but would encourage those site owners to move off this event for all the reasons described previously.
Impact
We've seen unload usage drop from 18% of navigations to under 4%. We expect some further droppage for clients that have not yet upgraded to a version of Chrome where this is deprecated but there will be some residual usage due to the opt-outs mentioned previously.
On the bfcache side, unload has reduced from being the sole blocker of 6% of navigations to around 1%, so an extra 5% of navigations have gained access to instant back/forward navigations through this work. In addition it has gone from being one of multiple bfcache-blocking reasons on 22% of potential bfcache navigations to around 3%, meaning if those other reasons are removed there is even more potential here.
Conclusion
Deprecating unload in Chrome was a long, but important, journey. We are pleased that the number of reports of breakages have been minimal which we believe is a testament to the careful consideration we put into the rollout of this change.
We don't remove APIs from the web platform often, but in this case we felt it was worthwhile to tackle this long-standing issue rather than allowing developers to continue to believe this API was worth considering for their website.