Safari released version 26.2 in December, adding support for the scrollend event and marking a significant milestone for the web platform. The release means the event now has baseline browser support across all major browsers, joining Chrome 114, Edge 114, and Firefox 109. The addition closes a longstanding gap in the platform’s scroll event model and eliminates the need for developers to rely on brittle workarounds when detecting that scrolling has finished.
The scrollend event fires once when scrolling definitively completes, whether triggered by user gestures, keyboard navigation, smooth scrolling, or programmatic JavaScript calls like scrollTo(). According to WebKit’s announcement, the event provides “a reliable signal that scrolling has finished” and addresses a problem that has plagued web developers for years. Previously, there was no native way to know when a scroll had truly ended. Developers were forced to guess using timer-based debouncing, typically with a setTimeout() delay of 100 milliseconds or more. This approach was imprecise, unreliable, and led to bugs where events would fire too late or while a user’s finger was still down on the screen.
Before scrollend, detecting scroll completion required code like this:
document.onscroll = event => {
clearTimeout(window.scrollEndTimer)
window.scrollEndTimer = setTimeout(callback, 100)
}
Now, with native browser support, the same result is achieved cleanly:
document.onscrollend = event => {
// scrolling has definitively ended
}
The browser handles all the complex evaluation internally, accounting for touch release, pointer release, keypress completion, scroll snap events, and visual viewport scrolling. The event does not fire if the scroll position did not actually change, avoiding spurious triggers.
Developer reaction to Safari’s implementation has been positive. A post on X highlighting the feature noted that it has been a long-awaited addition, outlining the benefits to their app:
I’ll now be able to properly save reading progress when the user stops scrolling, rather than having to use flaky poll-based logic…
A Stack Overflow discussion from before Safari’s support noted that developers needing cross-browser compatibility would require a polyfill, with packages like @af-utils/scrollend-polyfill filling the gap.
The practical applications for scrollend are broad. Chrome’s developer blog outlined common use cases including syncing carousel scroll positions with dot indicators, lazy-loading content after the user stops scrolling, updating UI based on final scroll position, fetching data after a user scrolls to a new tab, and logging analytics events. The event is particularly valuable for performance-sensitive operations. Running computationally heavy work during an active scroll can degrade the scrolling experience, but scrollend provides the perfect hook to defer that work until scrolling is no longer happening.
For teams still supporting older Safari versions, progressive enhancement is straightforward. Developers can detect support with 'onscrollend' and fall back to the timer-based approach when the event is unavailable. Polyfills offer another path, automatically using the native event when present and falling back to pointer and scroll event monitoring otherwise. The MDN documentation provides comprehensive examples and compatibility tables, noting that the feature is now baseline across all modern browsers.
The scrollend event is a reliable, cross-platform API for detecting when scrolling has completed. It fires when the browser finishes animating scroll, when user touch or pointer gestures are released, when keyboard navigation ends, and when programmatic scrolling via APIs like scrollTo() completes. It works on both document-level scrolling and individual scrollable elements, and correctly handles visual viewport interactions like pinch-zoom. For web developers who have spent years working around its absence, Safari 26.2’s implementation represents the final piece of a multi-year standards effort that began with Chrome 114 in 2023.
