Paste a URL — or upload your own full-page screenshot — and get a smooth scrolling video in a sleek browser or phone mockup, sized for YouTube, Reels, TikTok and LinkedIn.
We open it in a real Chrome, scroll the whole page so lazy images and scroll-in animations render, then stitch it into one tall screenshot.
Handles JavaScript-rendered sites, page builders and single-page apps. Sites that block automated browsers, sit behind a login, or hide behind a consent wall need the upload below.
PNG, JPG or WebP — click to browse.
✓ For pages behind a login, internal sites, or anything you would rather not send anywhere — this path runs entirely on your device.
⚠️ First, scroll slowly from the top to the very bottom of the page, then back up. Many sites (especially WordPress / Elementor) fade sections in as you scroll and load images lazily — if you skip this, those sections capture as blank. Scrolling through makes everything appear so your screenshot is complete.
F12 → Ctrl+Shift+P (Mac: ⌘+Shift+P) → type full → click Capture full size screenshot. Saves to Downloads.Then drag the PNG into the drop zone above.
🎬 The video is composed and recorded entirely on your device — no video ever leaves it. Capturing by URL sends the address to our own capture service, which loads the page itself; nothing from your browser is uploaded. Uploading a screenshot stays fully on your device.
"We just shipped a new homepage" lands 10× harder as a smooth scroll-through than a static screenshot — use it in newsletters, LinkedIn posts and Product Hunt launches.
Agencies: hand-deliver every site as a branded scroll video for proposals, case studies and Instagram reels.
Preview a long blog post, landing page or portfolio piece with a 10-second scroll that makes people want the full thing.
Tying video frames to scroll position creates the effect of an animation the reader controls — scrubbing through footage as the page moves. The technique became popular through high-profile editorial features, and the implementation detail that matters most is that video elements are not designed to be scrubbed frame by frame.
Seeking a video to an arbitrary time forces the decoder to find the nearest keyframe and decode forward from it, which is fast for playback and slow when done repeatedly at arbitrary positions. The result on many devices is visible stutter. Encoding with a very short keyframe interval — a keyframe every frame, in the extreme — makes seeking fast at the cost of a much larger file.
The alternative approach is an image sequence: pre-extract frames as individual images and swap them on scroll. This is completely reliable and gives exact frame control, but downloading hundreds of images is expensive, so it suits short sequences at modest resolution.
Scroll handlers run frequently and on the main thread, so work done inside them directly delays rendering. Reading layout properties inside a scroll handler forces synchronous layout, and doing it every event produces jank that is immediately visible.
The correct pattern is to record the scroll position in the handler and do the actual work inside requestAnimationFrame, so updates happen once per frame rather than once per event. Better still, modern CSS scroll-driven animations run off the main thread entirely, and where the effect can be expressed as an animation timeline rather than as arbitrary JavaScript, that is substantially cheaper.
Memory is the other constraint. A decoded frame at full resolution occupies width × height × 4 bytes, so buffering an image sequence at 1080p consumes memory quickly and will be terminated by mobile browsers. Reducing resolution is usually the honest fix — a scroll-driven sequence is typically small on screen and rarely needs full resolution.
Hijacking scroll is intrusive, and anything that alters the speed or direction of scrolling relative to input frustrates users and breaks assistive technology. Driving an animation from scroll position is acceptable; overriding scrolling itself is not.
Respect prefers-reduced-motion. Large scroll-linked motion is a known trigger for vestibular symptoms, and the media query lets you replace the sequence with a static image at no cost. WCAG 2.2 also requires that content is not lost when motion is disabled, so the underlying information must be available without the animation.
Plan the fallback deliberately. On a slow connection, a scroll-driven video may not load at all, and the page must still make sense — a representative still image with the accompanying text is the usual answer. Test with the network throttled and with JavaScript disabled, and check that keyboard users can reach and read the content, since scroll-linked content that only reveals itself on wheel events is unreachable by keyboard.
You usually do not have to. The URL capture runs a real headless Chrome, scrolls the whole page so lazy images and scroll-triggered animations render, and stitches the screenful-by-screenful result into one image, so JavaScript-rendered and animated sites come out complete. Upload is still the answer for pages behind a login, sites that block automated browsers, and anything you want kept private — the upload path is 100% local, so nothing leaves your device.
It depends on how tall your screenshot is and the speed setting. The estimated duration is shown before you generate. Most pages land between 8 and 25 seconds — ideal for social feeds.
Chrome and Edge export WebM (VP9). Firefox exports WebM (VP8). Safari exports MP4. All major platforms accept WebM. If you need MP4 from Chrome, use HandBrake or any free converter — it takes seconds.
Yes — log in, scroll through to make sure everything loads, then use DevTools "Capture full size screenshot". The screenshot contains exactly what was rendered in your browser, login session included.
Seeking a video to arbitrary times forces decoding from the nearest keyframe. Encode with a very short keyframe interval, or pre-extract an image sequence and swap frames instead.
Yes. Large scroll-linked motion can trigger vestibular symptoms. Honour prefers-reduced-motion with a static image, and make sure the information is still available without the animation.
Both, in effect. A video scroller normally means something that scrolls a page for you so you can film it; this does the scrolling and the recording in one step, from a still full-page screenshot, so there is no screen-capture software and no cursor in the shot. You get a deterministic scroll — same speed, same easing, same result every run — which a hand-scrolled screen recording cannot give you.