What Is Scrolljacking?
Scrolljacking is when a website takes your scroll input — the wheel turn, the trackpad swipe, the flick of a thumb — and decides for itself what happens next, instead of letting the browser do what it normally does. You’re not moving a page up and down anymore. You’re triggering the site’s own animation, one scroll at a time. It’s also called scroll hijacking, and depending on who you ask, that second name is the more honest one.
How it actually works
Under the hood, a scrolljacked site listens for your wheel, touch, or key events, cancels the browser’s default scroll, and plays its own transition instead — sliding a new section in, fading one panel into the next, snapping the viewport to a fixed point. This site is a working example: every section fills exactly one screen, and one scroll gesture moves you exactly one section. Nothing about it is a metaphor — it’s the literal mechanism behind the effect you’re watching right now.
Why it earned a bad name
Usability researchers have been warning about scrolljacking for close to a decade, and for most of that decade they were right. The typical implementation breaks things a browser is supposed to guarantee: the back button stops mapping to where you actually were, keyboard users hit a wall the moment tab order doesn’t match the visual flow, and motion keeps firing at people who told their operating system, explicitly, that they don’t want it. Add scroll-jank from JavaScript fighting the browser’s own compositor, and you get the reputation: flashy, and worse to use than a plain page.
None of that is inherent to the idea. It’s what happens when the trade-offs get ignored.
Why it’s coming back
A few years ago I found a CodePen by a designer named hrtzt — a one-page navigation menu that snapped between sections with a slide you could feel. I couldn’t stop thinking about it. I rebuilt the idea from scratch, in my own code, and kept pushing until it became the engine this whole site runs on. What changed since the bad old days isn’t the ambition — it’s the browser underneath it. The View Transitions API lets a page hand its transitions directly to the browser’s own compositor instead of faking them in JavaScript, which is what makes the motion here feel closer to native than to a demo reel. Same idea people have wanted for years. Different, sturdier foundation.
Scrolljacking, without the trade-offs
The fix isn’t a lighter touch on the same broken pattern — it’s answering each failure directly. Every section on this site is still a real page with a real URL, so the back button, bookmarking, and search indexing all work exactly like they would on any other website. Ask your system for reduced motion and the whole thing quietly becomes a normal, scrolling page — no animation, no scroll interception, nothing to opt out of because there’s nothing forcing itself on you. I go through the full mechanics, including the reduced-motion fallback and the View Transitions API specifically, on the web development page.
So: scrolljacking is a technique, not a verdict. It got a bad name because most people who used it didn’t build for the browser, or for the people navigating without a mouse. Build for both, and the thing everyone warned you about turns into the smoothest way to move through a website.