The scroll_video=true parameter records the browser scrolling through a page from top to bottom and returns a WebM video file. One extra parameter to the same endpoint, same auth. Instead of a static PNG you get a smooth 30fps recording that shows sticky headers, lazy-loaded images, scroll animations — everything a regular screenshot misses.
Below I'll walk through the parameters, the output format, and the workflows where animated screenshots actually make a difference.
How the scrolling screenshot API works
Pass scroll_video=true and the API loads the page, waits for content to render, then records the viewport scrolling from top to bottom. You get back a WebM video instead of an image.
curl "https://api.screenshotrun.com/v1/screenshots/capture?\
url=https://example.com\
&scroll_video=true\
&scroll_duration=8\
&scroll_speed=medium\
&width=1280" \
-H "Authorization: Bearer YOUR_API_KEY" \
-o scroll.webmThe response is a binary WebM file. No JSON wrapper, no base64, just the video. Open it in any browser or video player.
Scroll parameters
Three parameters control the recording:
| Parameter | Values | Default | What it does |
|---|---|---|---|
scroll_video | true | false | Enables scrolling video mode. Overrides the format parameter; output is always WebM. |
scroll_duration | 2–30 (seconds) | 5 | Total recording length. Longer pages with short durations scroll faster automatically. |
scroll_speed | slow, medium, fast | medium | Pixels per frame. Slow (2px), medium (4px), fast (8px). If the page is too long for the duration at the selected speed, the step size increases to fit. |
The recording pauses briefly at the top and bottom of the page (about 800 milliseconds each) so viewers see the start and end points clearly. Scroll motion runs at approximately 30fps. Smooth enough for product demos and social sharing without bloating the file.
Use cases for animated screenshot capture
Product teams grab these for demos and marketing. A scrolling video of your landing page performs better on social media than a static screenshot because it shows the full design in context: the hero, the feature sections, the testimonials, the footer CTA. Product Hunt launches, pitch decks, investor updates. Moving visuals get more clicks.
QA is where I find this most satisfying. A sticky header that jumps during scroll. Lazy-loaded images that flash white before rendering. CSS animations firing at the wrong scroll position. Layout shifts mid-page. A static full-page screenshot stitches everything together and hides these problems because you only see the final state. An animated screenshot exposes the actual scroll experience, exactly as a user would see it.
Documentation teams use them too. Instead of annotating 5 static screenshots to show how a settings page is organized, one scrolling capture walks through the entire page. Embed the WebM in your docs or convert it to a GIF for platforms that don't support video.
Sales teams doing outbound sometimes capture a scrolling video of a prospect's website for cold emails. More attention-grabbing than a static thumbnail, and it shows you actually looked at their site.
Combining with other parameters
Most capture parameters work alongside scroll_video. A few combinations that come up often:
# Scrolling video of a page behind login, with ads and cookie banners removed
curl "https://api.screenshotrun.com/v1/screenshots/capture?\
url=https://app.example.com/dashboard\
&scroll_video=true\
&scroll_duration=10\
&scroll_speed=slow\
&width=1920\
&block_ads=true\
&block_cookies=true\
&cookies=[{\"name\":\"session\",\"value\":\"abc123\",\"domain\":\"app.example.com\"}]" \
-H "Authorization: Bearer YOUR_API_KEY" \
-o dashboard-scroll.webmAuthentication via cookies and headers works the same way as static captures. Ad and cookie banner blocking cleans up the page before recording starts. wait_for_selector delays the recording until a specific element appears, which matters for dashboards and SPAs where content loads asynchronously.
Set delay=3 on pages with heavy JavaScript to let everything settle before the recording starts. dark_mode applies to scrolling videos too, handy for consistent branding across captures.
One parameter that does NOT apply: format. When scroll_video=true is set, the output is always WebM regardless of what you pass in format. full_page is also ignored since the scroll inherently captures the entire page.
WebM output and conversion
WebM (VP8/VP9 codec) plays natively in Chrome, Firefox, Edge, and Safari 15+. For contexts where you need a different format, ffmpeg handles the conversion:
# Convert to MP4 (H.264) for universal playback
ffmpeg -i scroll.webm -c:v libx264 -crf 23 scroll.mp4
# Convert to GIF (smaller palette, larger file)
ffmpeg -i scroll.webm -vf "fps=15,scale=800:-1" -loop 0 scroll.gifGIF files tend to be several times larger than the equivalent WebM for the same visual quality. GIF is limited to 256 colors and uses less efficient compression. For Slack, email, or platforms that don't embed WebM natively, GIF works despite the file size. For web embedding, stick with WebM. Smaller and sharper.
What animated screenshots don't cover
Scroll path is always top-to-bottom. No horizontal scroll, no custom scroll-to-selector targeting, and you can't scroll back up to create a loop. If you need a specific section mid-page, use the selector parameter for a static capture of that element instead.
Sticky elements (position: fixed) behave in video the way they behave for real users: they stay in frame the whole time. In a static full-page screenshot, those elements get frozen at one position and may overlap content they shouldn't. The animated version shows the real behavior, which is usually what you want.
No audio capture. This records what the viewport renders, not a full screen recording. For voiceover, capture the scrolling video via the API and add audio in post-production.
Getting started with the scrolling screenshot API
Add scroll_video=true to any capture request. Start with the defaults (5 seconds, medium speed) and adjust from there. Most landing pages look good at 8-10 seconds with medium or slow scroll speed. Honestly, the defaults work for most pages without any tuning.
Try it in the playground first. The scrolling video tab lets you preview the output before writing any code.
FAQ#
The API returns a WebM video file (VP8/VP9 codec). WebM plays natively in Chrome, Firefox, Edge, and Safari 15+. You can convert to MP4 or GIF using ffmpeg if needed. The format parameter is ignored when scroll_video=true is set.
Use scroll_duration (2-30 seconds) to set the total recording length, and scroll_speed (slow, medium, fast) to control pixels per frame. If the page is longer than the duration allows at the selected speed, the step size increases automatically to fit the full page.
Yes. Pass session cookies or authorization headers in the API request, the same way you would for a static screenshot. The scroll_video parameter works alongside all authentication parameters including cookies, headers, and wait_for_selector.
Yes. Elements with position: fixed stay in frame throughout the video, exactly as they would for a real user scrolling the page. This is different from static full-page screenshots, where fixed elements get frozen at one position.
Not currently. The scroll path is always top-to-bottom for the full page. There is no horizontal scroll, no scroll-to-selector targeting, and no option to loop back up. For capturing a specific section, use the selector parameter for a static element screenshot instead.