Browser support

What vidscroll needs from the browser, what changes without it, and what has been tested.

Scroll-driven video itself works in every current browser. What varies is whether a slow-to-scrub video can be fixed on the spot.

What each feature needs

Feature	Needs	Without it
Scrubbing, pinning, sections	The `video` element and CSS `position: sticky`	Available in all current browsers
In-browser re-encoding	WebCodecs (`VideoDecoder` and `VideoEncoder`)	The original file is used; scrubbing is as smooth as the file allows
Caching the re-encoded copy	Cache Storage	The re-encode runs on every visit
Re-encoding and caching	A secure page: HTTPS or `localhost`	Both are off, so plain-HTTP pages behave like browsers without WebCodecs

A video prepared with npx vidscroll encode needs none of the optional features, which is why preparing files is the most reliable setup.

Source: caniuse.com/webcodecs, October 2026.

Environment	Status
Chrome on Windows	Tested, including automated tests
Firefox on Windows	Tested, including automated tests
WebKit (Playwright’s Windows build)	Tested; it has no WebCodecs, so raw videos aren’t re-encoded
Android phone (Chromium-based browser)	Tested by hand
Next.js 16 with React 19	Tested: server rendering, hydration, server components
Safari on macOS, iPhone and iPad	Not yet tested

Firefox may refuse to re-encode more than one video at the same time on a page; the others keep their originals.
Android browsers use forward playback when scrolling forward, which is smoother there than seeking.
Low Power Mode and similar settings that block video playback make vidscroll fall back to seeking for every frame.
Older browsers without svh units use vh for the stage height.