Chrome's unload Event Deprecation Hits Its Final Rollout Date: What Site Owners Should Check

If your website or web application still relies on the browser's unload event to save data, send analytics or clean up a session when a visitor leaves, that code is now scheduled to stop running in Chrome. According to Chrome's documentation on deprecating the unload event, the rollout was planned to reach 100% of Chrome page loads on September 22, 2026, with Chrome milestone 154.

This is not a new feature to adopt. It is a change in default behavior that can quietly break things on sites that have not been touched for years, which is why it matters to anyone responsible for website and web application development or for maintaining an older product.

This article explains what Chrome has changed, how the rollout was staged, what is likely to be affected, and what a business owner or product manager should ask their developers to check.

What Chrome changed

The unload event is a signal browsers have historically sent to a page just before it is discarded, for example when a visitor closes the tab or navigates elsewhere. Developers attached "handlers" to it: small pieces of code meant to run at the last moment.

Chrome's documentation states that once the deprecation applies, unload handlers stop firing on a page unless that page explicitly opts in to re-enable them. The code is still there and nothing throws a visible error. It simply never runs.

The same document describes the schedule. Chrome first applied the change to a small group of very popular sites, growing to 50 sites during 2025. In 2026 it began rolling out to all sites over 8 milestones, or about 32 weeks.

The rollout timeline

The timeline table in Chrome's documentation, which the page says was updated as of June 29, 2026, lists these steps for general page loads:

• Chrome 146, March 10, 2026: 1%
• Chrome 147, April 7, 2026: 5%
• Chrome 148, May 5, 2026: 10%
• Chrome 149, June 2, 2026: 20%
• Chrome 150, June 30, 2026: 40%
• Chrome 151, July 28, 2026: 60%
• Chrome 152, August 25, 2026: 80%
• Chrome 154, September 22, 2026: 100%

Chrome notes that the percentages are based on page loads, applied consistently over time, rather than on individual users or sites. In practice that means a problem may have appeared for some visits months ago and only become consistent now. Note that these are the dates published in the schedule; we have not seen a separate announcement confirming the final step, so treat September 22, 2026 as the planned date.

Why Chrome is doing this

Chrome gives two reasons in its documentation. The first is reliability. On mobile browsers the unload event often does not run at all, because tabs are frequently sent to the background and then killed by the operating system. Chrome also notes that Safari behaves this way on desktop. Code that depends on unload has therefore been losing data on a share of visits for a long time.

The second reason is speed. Browsers keep a snapshot of a page in memory so that pressing Back or Forward restores it instantly. This is called the back/forward cache, or bfcache. Chrome's documentation explains that an unload handler prevents a page from using this cache, so one old script can make every Back navigation on a site slower.

What is likely to break

The following is our interpretation of where problems tend to hide, not a list published by Chrome. The pattern to look for is any logic that assumes "the user is leaving now, so do this one last thing."

• Analytics or tracking code that sends its final data, such as time on page, when the page unloads.
• Forms or editors that save a draft at the moment of leaving.
• Session, cart or booking logic that releases a lock or reservation when the tab closes.
• Older third-party widgets, chat tools or embedded frames that register their own unload handlers.

Because nothing visibly fails, the symptoms are indirect: analytics numbers that drift, drafts that are not saved, or records that stay locked until a timeout. Sites built several years ago, and sites with many third-party scripts, deserve the closest look.

What it means for your business

For most modern sites this change will pass unnoticed, and it may make Back and Forward navigation feel faster. The risk sits with older or heavily customized systems where no one remembers what runs at page exit.

If your reporting depends on end-of-visit data, a silent drop in Chrome can distort decisions made from those numbers. If an internal tool relies on unload to free a record for the next user, staff may see more "locked by another user" situations. Neither is dramatic, but both are the kind of slow, hard-to-diagnose issue that costs time.

It is also worth being realistic about the alternative. Since unload was already unreliable on phones and in Safari, code that depends on it was already failing for part of your audience. Fixing it properly improves behavior in every browser, not only Chrome.

What developers should use instead

Chrome's documentation recommends different events depending on the goal. To know when a page is no longer visible to the user, use the visibilitychange event, which is the most dependable point to save state or send analytics. To know when the user has navigated away, use pagehide. To warn someone about unsaved changes, use beforeunload, although Chrome recommends limiting its use and only attaching it while there really are unsaved changes.

Finding the handlers

Chrome lists several ways to locate unload handlers, including ones added by third-party code: the back/forward cache test in Chrome DevTools, the Reporting API, and the notRestoredReasons API that reports why a page could not be restored from bfcache. Developers can also turn on the chrome://flags/#deprecate-unload setting to force the new behavior locally and test a site against it.

The temporary opt-out

If a fix cannot be shipped quickly, a page can opt back in. The explainer linked from Chrome's documentation shows a Permissions-Policy response header with the value unload=self for the top-level page. For an embedded frame, the header must be present on that frame and every frame above it, and each containing iframe element needs allow="unload". For managed company devices, Chrome documents an enterprise policy named ForcePermissionPolicyUnloadDefaultEnabled and says it plans to support that opt-out for the considerable future. Treat both as a bridge, not a destination, because the opt-out keeps the bfcache penalty and does nothing for other browsers.

What to do next

Ask your development team or agency for a short audit rather than a rewrite. A sensible sequence is to search the codebase and third-party scripts for unload handlers, test the main user journeys in Chrome with the deprecation flag enabled, and compare analytics from before March 2026 with recent weeks for unexplained changes in exit or duration metrics.

Where handlers are found, move the logic to visibilitychange or pagehide, and replace "release on close" logic with server-side timeouts that do not depend on the browser at all. For third-party tools, check whether a newer version of the script exists. Use the opt-out header only if a business-critical flow is broken and a proper fix needs more time.

Conclusion

Chrome's deprecation of the unload event has been announced for years and, per Chrome's published schedule, was due to cover all page loads on September 22, 2026. The effect is silent: exit-time code stops running unless a page opts in. Most sites will be fine, but older applications, custom internal tools and pages loaded with third-party scripts should be checked.

If you maintain an older site and are not sure what it does when a visitor leaves, a small review now is cheaper than chasing missing data later. If you would like a second pair of eyes on it, you can request a quote for a browser compatibility review.