Yes, it can. Chrome has completed its deprecation of the unload event, so handlers no longer run by default unless a site opts out. A third party script that sends its last analytics beacon or saves state in unload can lose that data, and nothing on your page will warn you.
What changed
Chrome for Developers documents the deprecation of the unload event as complete in Chrome. The event no longer fires by default and unload handlers do not execute, unless a site has explicitly opted out to re-enable them. The same page notes that they may still fire in Chrome on iOS, because that uses the same WebKit engine as Safari rather than Chrome's own engine.
So the behaviour now differs by browser. Code that worked everywhere a few years ago is now unreliable on one of the most used browsers.
Why this is a vendor risk, not just your code
You can fix your own pages. You cannot fix a script you load from another company. Tag managers, chat widgets, session recording tools, ad scripts and some payment helpers have used unload to flush queues or release locks.
web.dev's guidance on the back/forward cache goes further. It says the most important way to optimise for bfcache in all browsers is to never use the unload event, because it predates bfcache and many pages assume the page will not continue to exist afterwards. A page with an unload handler may be kept out of the cache, which makes back navigation slower.
That gives two failure modes.
| Failure | What you see |
|---|---|
| Handler does not run | Missing final events, unsaved state, orphaned sessions |
| Handler present in other browsers | Back navigation misses the cache, feels slower |
How to find affected scripts
- Open your key pages in Chrome DevTools and use the application panel to check back/forward cache eligibility. It reports reasons a page was not cached.
- Search your own bundle for unload listeners.
- For vendor scripts, search the loaded files for the string unload, then check whether it sits in your code or theirs.
- Compare analytics session counts and last page events before and after Chrome versions that changed this behaviour, looking for a drop in final beacons.
What to ask the vendor
- Do you rely on unload anywhere in the script?
- Which events do you use instead? The usual replacements are pagehide and visibilitychange, which fire reliably when a page is hidden or navigated away from.
- Do you send final data with a beacon or a keepalive request?
- What is your supported browser list and your policy for browser deprecations?
A vendor that cannot answer is a signal. Record the answer in your vendor register along with the date.
Fixing it on your side
If you control the page, replace unload with pagehide or visibilitychange and keep the work small. For scripts you load, update to the vendor version that has fixed it. If none exists, plan a replacement with a date, because a script you cannot patch becomes a standing risk. Our post on what to do when an SDK is abandoned applies to web scripts as well.
Where Safeguard fits
Safeguard's dependency scanning covers the packages in your web application, so you can see which client libraries ship with a build. Scripts injected at runtime by a tag manager need a separate inventory. A free scan is at gold.safeguard.sh/scan.
Quick check
Is unload gone from every browser?
No. The Chrome documentation says handlers may still fire in Chrome on iOS because it uses WebKit. Behaviour differs by browser, so test more than one.
What should replace unload?
pagehide and visibilitychange are the commonly recommended events, since they fire when the page is hidden or navigated away from.
Sources
- Chrome for Developers, Deprecating the unload event: https://developer.chrome.com/docs/web-platform/deprecating-unload
- web.dev, Back/forward cache: https://web.dev/articles/bfcache
Last reviewed: 19 October 2026.
