DEV Community: Keny Alba

Seedance 2.5 Goes 4K for 20 Studios: Verified Prices, Draft Mode Math, and Who Can Actually Use It

Keny Alba — Tue, 27 Oct 2026 12:34:28 +0000

ByteDance just put a 4K label on its best video model, and the headlines wrote themselves. The more interesting story is quieter: who is actually allowed to use that 4K mode (almost nobody: around 20 studios, according to a single press report, relayed but not confirmed by ByteDance), what the public model really costs per generated second (we recalculated it from the official formula), and a billing mechanism called Draft mode that changes how studios iterate, without making any single video cheaper.

Everything below comes from official ByteDance, Volcano Engine and BytePlus documentation, cross-checked with dated press. We did not test the 4K model ourselves: access is enterprise-only, and we will not pretend otherwise.

What just shipped: Seedance 2.5 4K in enterprise trial

On October 23, 2026, Volcano Engine, ByteDance's cloud arm, officially presented Seedance 2.5 4K as the strongest model of its 2.5 generation, with extra training on facial expressions, micro-movements and fine image detail (Yicai, October 23).

The day before, Chinese tech outlet Leiphone reported that the first enterprise trial batch is deliberately tiny: around 20 studios and directors worldwide, tied to real big-screen productions (Leiphone, October 22). According to that report, 20 productions are underway, the first one, an S-tier satellite TV IP, could air as early as November, and a major global film IP is involved. One testing studio told Leiphone its costs came in "lower than expected", thanks to a 480p-first workflow. Keep in mind this "20 studios" figure traces back to that single report, even if other outlets (TMTPost, Beijing News) relayed the trial the same day.

Two things are certain. Access is invitation-only, with wider availability described as possible later, not promised. And no 4K price for Seedance 2.5 has been published anywhere.

One fact almost every headline missed: native 4K output is already on sale to the public, on the previous generation. Seedance 2.0 has a listed 4K tier on both Ark in China (25.27 CNY, about 3.8 USD, per 5-second clip) and BytePlus internationally (3.89 USD per 5-second clip, capped at 15 requests per minute and 1 concurrent job). What is new this week is not 4K itself. It is native 4K on the new 2.5 model, the one that generates audio and video jointly, runs up to 30 seconds and accepts up to 50 reference assets, with film productions in its sights, not 4K in the abstract.

What the model actually does

Seedance 2.5, the base model that went generally available in August, is described by ByteDance's Seed team as a "next-generation audio-video joint generation model" (seed.bytedance.com). Joint is the keyword: the model generates sound together with the picture, not as an afterthought.

From the official pages, verified on October 25-26:

Length: up to 30 seconds in a single generation, with the option to extend twice.
References: up to 50 reference assets in one run, 30 images, 10 videos and 10 audio files, according to the BytePlus model page. Seed says the model reads a reference video's intention, framing and cinematic language, "beyond motion transfer into creative interpretation".
Editing: localized in-video editing, white-model (clay-style mannequin) control, green-screen editing, and what Seed calls professional camera movement and blocking.
Languages: native support for 10+ languages (BytePlus).
Public output specs: 4 to 30 seconds, 480p, 720p or 1080p, at 24 FPS, MP4 or MOV (BytePlus).

That last line is the one to remember: publicly, Seedance 2.5 tops out at 1080p on both the Chinese and international platforms. The 4K tier exists only inside the enterprise trial.

Draft mode: the innovation that saves money, not the one that impresses

Buried in Volcano Engine's Ark pricing documentation is a mechanism called Draft mode, and it explains the trial studio's "lower than expected" comment better than any benchmark. Its exact wording, translated from Chinese:

"Seedance 2.5's Draft mode consists of two tasks, each billed separately"

Source: Volcano Engine's Ark pricing documentation, in Chinese, verified on October 27, 2026.

A Draft generation is billed as two separate tasks:

Step 1: a draft video, billed at 480p rates.
Step 2: the final video at the target resolution. The draft's own tokens do not count toward step 2, and the per-token rate is set by whether step 1 included an input video.

We verified the official token formula against Ark's own price examples, and it checks out to the cent: tokens = duration in seconds x width x height x FPS / 1024, at 24 FPS. A 5-second 1080p clip is 5 x 1920 x 1080 x 24 / 1024 = 243,000 tokens, which at 77 CNY per million tokens gives 18.71 CNY, exactly Ark's listed example.

Now the interesting comparison, for a 10-second 1080p shot without input video:

Direct generation: 486,000 tokens = 37.4 CNY (about 5.6 USD, indicative conversion at the October 27 rate of roughly 0.15 USD per CNY).
Draft path: step 1 at 480p costs 96,075 tokens = 6.7 CNY (about 1 USD), then step 2 costs the same 37.4 CNY as a direct run. Total: 44.1 CNY (about 6.6 USD).

Read that again, because it is the opposite of what "draft mode saves money" usually means. One finished video through the draft path costs more than one direct generation. What gets about 5.6 times cheaper is each iteration: 6.7 CNY per 480p attempt instead of 37.4 CNY per 1080p attempt. If you reject five drafts before approving one, that is six draft attempts plus the final render: 6 x 6.7 + 37.4 = 77.6 CNY (about 11.6 USD), instead of six direct 1080p tries at 6 x 37.4 = 224.4 CNY (about 33.7 USD). The draft is a cheap rehearsal, not a discount.

(One caveat: when your input already contains video, Ark applies a minimum token usage, so very short inputs do not shrink the bill below that floor.)

What a generated second really costs

Two official price lists exist, and they are not currency conversions of each other. Treat them as separate markets.

Volcano Ark, China (doubao-seedance-2.5, per million tokens, online inference):

Resolution	No input video	With input video
480p / 720p	70 CNY (approx. 10.5 USD)	42 CNY (approx. 6.3 USD)
1080p	77 CNY (approx. 11.6 USD)	46 CNY (approx. 6.9 USD)

Dollar amounts are indicative conversions at the October 27 rate (roughly 0.15 USD per CNY, CNY/USD quote observed on exa.ai). Ark bills in CNY; these are not dollar list prices.

Official worked examples, 5 seconds, 16:9: 3.36 CNY (0.50 USD) at 480p, 7.56 CNY (1.13 USD) at 720p, 18.71 CNY (2.80 USD) at 1080p. A 28% promotion on 1080p ran from August 14 to October 17 and has now ended.

BytePlus ModelArk, international (Dreamina-Seedance-2.5, per million tokens): 10.7 USD without input video, 6.4 USD with input video. The official example works out to 0.514 USD for a 5-second 480p clip. Seedance 2.0, the previous generation, carries the public native 4K tier at 3.89 USD per 5-second clip.

What that means in practice at international list prices: a 10-second 1080p shot costs about 5.20 USD in tokens, and a maximum-length 30-second generation about 15.60 USD. A rejected draft at 480p costs about 1.03 USD on the Chinese list, where Draft mode is documented; BytePlus's international docs do not describe Draft mode at the time of writing, so we will not claim it there. Per second, still at list price without input video: about 0.103 USD/s at 480p and 0.52 USD/s at 1080p (16:9, 24 fps).

Who can use it today, and who cannot

The 4K model: the trial studios, full stop. If a vendor offers you "Seedance 2.5 4K" access today, be careful: AIFilmHQ noted on October 23 that some resellers sell 1440p and 4K tiers that are upscales of 1080p output, not native generations (aifilmhq.com). That outlet also mentions 10-bit color for the 4K tier; we found no primary confirmation of that detail.

The public 1080p model, international: BytePlus ModelArk, ByteDance's international platform, sells Seedance 2.5 with a real entry ticket: activation requires at least 30 USD through one of three routes in the official activation doc:

Activation route	Minimum	Detail
Credits	30 USD	prepaid top-up
Dedicated AI Savings Plan	30 USD	30, 60 or 100 USD tiers
Resource pack	30 USD	valid for 90 days

There is no free quota for this model. On the consumer side, Dreamina (the international name for Jimeng, distributed with CapCut) offers Light and Production plans; those plans are explicitly non-refundable and fall back to pay-as-you-go when exhausted.

The public model in China: Volcano Ark for API access, Jimeng and Doubao for app usage.

Third parties: API resellers like OpenRouter carry Seedance models. The confusion is real enough that a Hacker News thread from August (news.ycombinator.com/item?id=49140823) opens with a user, r0fl, asking "Where can you use seedance to make movies? Do you have to sign up to a third party? [...] I just can't figure it out!!" The replies map the maze: Jimeng, Dreamina, Doubao, BytePlus, resellers. One reply notes there is no way to see subscription pricing without creating an account.

Reproduce the draft-to-final logic on your own footage

You do not need Seedance access to benefit from the draft idea: it is just resolution discipline. We ran the following on October 26 with ffmpeg 4.4.2 on a synthetic 30-second 1080p24 clip (26.7 MB), and the numbers below are the real outputs.

Extract one reference frame every 5 seconds, at 480p width, for storyboard validation:

ffmpeg -i master-1080p.mp4 -vf "fps=1/5,scale=854:-1" frames/%03d.jpg

Result: 6 JPEG frames at 854x480, 25 to 39 KB each.

Render a 480p draft proxy for edit approval:

ffmpeg -i master-1080p.mp4 -vf scale=854:480 -c:v libx264 -crf 28 proxy-480p.mp4

Result: 895 KB, about 3.4% of the master's size, same duration and frame rate.

One nuance worth keeping: the file shrank 30-fold, but a generation API does not bill file size, it bills pixels. A 480p frame holds 19.8% of the pixels of a 1080p frame, which is why a 480p draft costs roughly one fifth of the tokens, not one thirtieth. Whether you are validating an edit locally or iterating on a paid model, the habit is the same: approve the cheap version, pay for the expensive one once.

What this launch says about the video model race

The race of late 2026 is not resolution, it is sustained coherence. Kuaishou launched Kling 4.0 on October 15 (official press release) with native 30-second single-pass generations and an Omni Reference system handling up to 15 reference assets and 10 keyframes; API access for enterprise customers is announced as coming soon. ByteDance answers with 30-second joint audio-video generation, reference libraries of 50 assets, and an enterprise 4K tier aimed at theatrical productions, plus industrial uses like robotics simulation (Leiphone).

Notice where the differentiation happens: billing mechanics, reference control, editing. Draft mode is a procurement feature as much as a creative one. The studios in this trial are not testing whether AI video looks good. They are testing whether it fits a production budget and a post-production pipeline. That is a maturity signal for the whole category.

Limits and what we do not know yet

This article is documentation analysis, not a hands-on review. The 4K model is inaccessible to us, trial results have not been independently verified, and the "20 studios" figure rests on one report. No 4K price or general availability date has been published for Seedance 2.5. The 10-bit color detail comes from a single secondary source. BytePlus's international documentation does not describe Draft mode, so the draft math above is anchored to the Chinese Ark list. Prices and access rules can change at any time; every figure here carries its verification date.

Key takeaways

Seedance 2.5 4K is real but locked in an enterprise trial of about 20 studios. Public Seedance 2.5 tops out at 1080p; public native 4K already exists on the older Seedance 2.0.
The model generates audio and video jointly, runs up to 30 seconds (extendable twice), takes up to 50 reference assets, and edits footage locally.
Draft mode bills a 480p rehearsal plus the final render: each iteration costs about 5.6 times less, not the final video.
Verified costs: 5 seconds of 1080p = 18.71 CNY (about 2.8 USD) on Ark, 5.20 USD for 10 seconds of 1080p at BytePlus international list prices, 3.89 USD for 5 seconds of native 4K on Seedance 2.0.
International access starts at 30 USD on BytePlus ModelArk. Beware resellers advertising "4K Seedance 2.5": it may be upscaled 1080p.
The draft habit is free to copy: iterate at low resolution, render final once. Two ffmpeg commands above get you there on your own footage.

Sources

Official sources:

Seedance 2.5 product page (ByteDance Seed)
Volcano Engine Ark pricing, China: prices and token formula verified on October 27, 2026
BytePlus ModelArk pricing, international: verified on October 26, 2026
Seedance activation on BytePlus ModelArk
BytePlus Seedance 2.5 page: public limits (1080p max, 50 assets)
Kling 4.0 press release (Kuaishou IR, October 16, 2026)

Press:

Yicai, October 23, 2026: enterprise 4K trial announcement
Leiphone, October 22, 2026: sole source for the "20 studios" figure
TMTPost, October 22, 2026 and Beijing News, October 22, 2026: same-day trial coverage
AiFilmHQ, October 23, 2026: secondary source (10-bit color, resellers)

Community:

Hacker News thread: access-confusion case, cited with attribution

Chrome's Prompt API is stable: on-device AI for your website, no API key and no per-token bill

Keny Alba — Sun, 25 Oct 2026 11:59:15 +0000

Calling a language model from a web page no longer requires an API key, a per-token invoice, or sending user data to a server. Chrome's Prompt API, powered by Gemini Nano, is stable in extensions since Chrome 138 and on the web since Chrome 148: a page in Chrome can ask the browser to summarize, classify or rewrite, locally. For extension developers, this is a category shift: AI becomes a browser capability, on par with storage or notifications.

It is not magic, though. The model downloads on first use, it can be absent (insufficient hardware, limited storage), and the API surface differs subtly between the web and extensions. Without serious feature detection and a fallback, your "smart" feature becomes a dead button for part of your users.

This guide builds the complete pattern from the official documentation: detect, create a session, stream the response, handle the model download, and fall back cleanly to a backend when Nano is not there. The code is self-contained, testable in the console, and honest about its limits.

Contents:

What is stable, what is not
How it works under the hood
Hands-on: the detect, create, stream pattern
Web or extension: the differences that matter
Anti-pattern: calling without checking availability
Edge cases and failures
How to measure and verify
Privacy and architecture questions before you ship
Designing a reusable, measurable session
Key takeaways

What is stable, what is not

As of October 22, 2026, the official documentation draws this map:

API	Extensions	Web
Prompt API (LanguageModel)	Stable since Chrome 138	Stable since Chrome 148
Summarizer, Translator, Language Detector	Stable since Chrome 138	Stable since Chrome 138
Writer, Rewriter, Proofreader	In development	In development
Sampling parameters (`samplingMode`)	Legacy topK/temperature	Origin trial only

Two clarifications that save debugging hours. First, the current surface is called LanguageModel: old examples based on window.ai date from the 2024 previews and throw errors. Second, expired origin trial permissions (aiLanguageModelOriginTrial) must be removed from extension manifests; the documentation calls this out explicitly.

How it works under the hood

The model doing the work is Gemini Nano, downloaded once by the browser and shared across origins. Your site does not ship the model, Chrome does, which is why there is no key and no billing. Three practical consequences:

The first call triggers a potentially long download, to be treated as a first-class interface state.
The exact size varies with browser updates (chrome://on-device-internals shows the current value), and if available space drops below 10 GB after download, Chrome removes the model.
Supported languages are limited at this stage: English, Japanese, Spanish, German and French for text inputs and outputs; inputs can also be image or audio, outputs remain text.

Hands-on: the detect, create, stream pattern

The following block is self-contained: paste it into the console of an HTTPS page on Chrome 148+, or into an extension service worker on Chrome 138+. It illustrates the rhythm the API imposes: the same options to availability() and create(), then response streaming.

// prompt-api-pattern.js - paste into the console (Chrome 148+ web, 138+ extension)
async function askOnDevice(question, onToken = console.log) {
  // 1. The SAME options go to availability() and create():
  //    an unsupported modality is only detectable this way.
  const options = {
    expectedInputs: [{ type: 'text', languages: ['en'] }],
    expectedOutputs: [{ type: 'text', languages: ['en'] }]
  };

  if (!('LanguageModel' in self)) return { source: 'fallback' };

  const status = await LanguageModel.availability(options);
  if (status === 'unavailable') return { source: 'fallback' };

  // 2. create() triggers the download if needed;
  //    plan a visual indicator while it downloads.
  const session = await LanguageModel.create({
    ...options,
    monitor(m) {
      m.addEventListener('downloadprogress',
        e => console.log(`Model: ${Math.round(e.loaded * 100)}%`));
    }
  });

  // 3. Streaming: each chunk is a delta (only the new tokens,
  //    the API's current behavior): accumulate them.
  let text = '';
  const stream = session.promptStreaming(question);
  for await (const chunk of stream) { text += chunk; onToken(chunk); }
  session.destroy();
  return { source: 'on-device', text };
}

const result = await askOnDevice('Summarize in one sentence what the Prompt API is.');
if (result.source === 'fallback') {
  console.log('Nano unavailable here: fall back to your cloud backend.');
}

Verification: on a compatible machine, the first call shows download progress, then the streamed answer; on an incompatible one, the code prints the fallback path. If availability() returns downloadable, create() starts the download (user activation may be required).

For typing, the @types/dom-chromium-ai package provides TypeScript definitions for the Prompt API and the other built-in AI APIs.

Web or extension: the differences that matter

Aspect	Web (Chrome 148+)	Extension (Chrome 138+)
Sampling	`samplingMode` via origin trial only	`topK` / `temperature` supported
Download trigger	User activation required	Same, but privileged context
Typical use cases	Page summaries, assisted forms	Background processing, side panel
Legacy trial permission	Not applicable	Must be removed from the manifest

For an extension, the older stability window (138) is a real competitive edge: the server-side AI extension market charges for what Chrome offers here for free, offline, without sending the user's page to a third party.

Anti-pattern: calling without checking availability

// Avoid: session created blind
const session = await LanguageModel.create();
const out = await session.prompt('Summarize this page.');
// On a machine without Nano: unhandled exception,
// a surprise download mid-user-action,
// and no way out. The "AI" button becomes a trap.

The correct pattern first tests 'LanguageModel' in self, then availability() with the exact options, and always keeps a way out. Without that, the most modern feature in the product is also the most fragile.

Edge cases and failures

Situation	Documented behavior	What to do
`availability()` = `unavailable`	Incompatible hardware or policy	Cloud fallback, hide the feature
`availability()` = `downloadable`	Model not on device yet	`create()` starts the download, inform the user
Storage < 10 GB after download	Chrome removes the model	Expect re-download, do not treat as a bug
Language outside en/ja/es/de/fr	Not supported at this stage	Detect language first (Language Detector API)
`temperature` on the web	Not exposed by default	`samplingMode` via origin trial, or leave unset
Long session left open	Memory retained	`session.destroy()` after use, as in the pattern
JSON output expected	No schema constraint on text output	Validate and retry application-side

How to measure and verify

Three quick checks are enough before shipping:

chrome://on-device-internals confirms the model's presence and current size.
An offline test (airplane mode) must work once the model is downloaded: that is the whole promise.
Measure time to first token (performance.now() before create() and at the first stream iteration) on an entry-level machine: that latency, not yours on a MacBook Pro, is what your users will live with.

Privacy and architecture questions before you ship

The Prompt API's appeal (a language model built into the browser, no backend bill, no API key) comes with design questions a quick demo never raises. The first is privacy posture. On-device inference means user text does not have to leave the machine, which is a genuine architectural win for sensitive contexts. But "can stay local" is not the same as "stays local": the moment your feature falls back to a server model for unsupported browsers or heavier tasks, your data-flow diagram has two paths, and your privacy notice must describe both. Decide the fallback policy before the first user prompt, not after the first support ticket.

The second question is capability honesty. A built-in model is a generalist; it will summarize a support ticket and draft a reply, but it is not your fine-tuned domain model and it will not know your product catalog. Features that need your data still need your backend. The healthy pattern is a split brain: the browser model handles user-private, latency-sensitive text work, and your server handles anything that requires your knowledge.

The third question is durability. Browser APIs evolve; the extension surface reached stability earlier than the web surface. Gate the feature, detect availability at runtime, and degrade gracefully. Your users on other browsers will thank you for a good fallback far more than for a badge saying "Chrome only."

Designing a reusable, measurable session

The official documentation provides the two primitives that structure everything else: LanguageModel.availability() to know whether the model is ready, and LanguageModel.create() to open a session. The detail that makes the difference in production hides in an easy-to-miss caution: you must pass availability() exactly the same options as prompt() or promptStreaming(), because some models do not support every modality or language. In other words, availability is tested per configuration, not in absolute terms.

Architecture-wise, three habits pay off. One session per intent rather than one global session: the expectedInputs and expectedOutputs parameters (modalities and languages) are declared at creation, and a ticket-summarization session does not have the same shape as a translation session. An explicit download monitor: the official example shows the downloadprogress event at creation, and an interface that displays model-download progress avoids the "frozen app" feeling on first use. A measured fallback: when availability() says no, switch to your server path while logging the reason; that log is what will tell you, three months from now, whether the local feature deserves to be expanded.

Key takeaways

The Prompt API is stable: extensions since Chrome 138, web since Chrome 148; it is called LanguageModel, not window.ai.
Gemini Nano is downloaded and shared by Chrome: no key, no bill, but an initial download to handle and possible removal under 10 GB free.
The golden rule: same options for availability() and create(), and always a cloud fallback for incompatible devices.
Web and extensions do not share the same surface: fine sampling control remains an extension perk (or an origin trial).
The decisive argument is privacy: on-device inference keeps prompts and page content on the machine, which simplifies many a conversation with the security team. On unsupported devices, what leaves the machine depends on your fallback implementation.

This guide is maintained on the ScrollFlow blog, where it was first published and corrected: Chrome's Prompt API: On-Device AI for Your Websites. Speaking of Chrome extensions: ours, ScrollFlow, records your web pages as video with automatic scrolling, 100% locally. If on-device AI speaks to you, local processing should too: Chrome Web Store.

What are you building with on-device AI? Curious to read your use cases in the comments.

References and further reading

Chrome for Developers - Prompt API: official documentation (138/148 stability, LanguageModel, availability(), sessions, multimodal, languages). https://developer.chrome.com/docs/ai/prompt-api
Chrome for Developers - Get started with built-in AI: overview of the built-in AI APIs and Gemini Nano. https://developer.chrome.com/docs/ai/get-started
Chrome for Developers - Built-in AI APIs: status of each API (Summarizer, Translator, Writer, etc.). https://developer.chrome.com/docs/ai/built-in-apis
MDN - LanguageModel.promptStreaming(): streaming behavior and examples (delta chunks, accumulation). https://developer.mozilla.org/en-US/docs/Web/API/LanguageModel/promptStreaming
npm - @types/dom-chromium-ai: official TypeScript definitions for the built-in AI APIs. https://www.npmjs.com/package/@types/dom-chromium-ai

Auto-scroll is not `window.scrollTo`

Keny Alba — Wed, 02 Sep 2026 14:30:00 +0000

The document you measure is not always the document you see

This is the last post in a five-part series about recording a page while it moves. Capture models and clocks do not matter if the page does not move the way you think it does.

window.scrollTo(0, y) is the demo. Production sites are scroll-snap, Lenis-class smooth engines, overflow-owned layouts, and WebGL scenes that never exposed scrollHeight.

document.documentElement.scrollHeight is a good default. It is not a contract.

Marketing pages put the real scroll on an inner div with overflow: auto. Animation libraries put a hidden scroller in the tree and map it onto transforms. Canvas scenes consume wheel events and draw a camera. The window’s scrollY barely changes. Auto-stop based on “near scrollHeight - innerHeight” fires immediately, or never.

I detect overflow boxes and drive their scrollTop as well as the window. That over-fires on pages that have a small scrollable code sample. A short article with a modal or a widget can hijack the “page” height. The safer filter is: only trust a container that covers most of the viewport. I still miss some owners and still grab some widgets. It is a heuristic.

Wheel events have to look like a user. Libraries check hover before they honor wheel. Dispatching only on document is not enough. I target the element under the pointer (or the simulated pointer), bubble a wheel, and also hit the first canvas if the pointer is on an overlay. Isolated-world scrollTo never entered that canvas’s event path.

Smooth-scroll engines keep their own target in a requestAnimationFrame loop. After I jump to the top, they interpolate back to where they were. The first seconds of a capture show the page sliding away from y = 0. The counter is a freeze: keep forcing top until preparation delay ends, then release. At the bottom, stop sending deltas. Footer widgets and WebGL listeners bounce if you keep ticking. Syncing the engine’s internal offset to the real scrollY is a last poke, not a second scroller.

Snap is a feature until it is a fight

CSS scroll-snap will fight a linear scrollBy every frame. The page looks possessed: you ask for two pixels, it jumps a section, you ask again, it jumps back.

For ordinary auto-scroll I disable scroll-snap-type on the tree. The recording is a continuous move. That is the point.

For section-based sites, that disable is the bug. Those pages are the snap. I use a different driver: one synthetic wheel impulse, then silence, then another. Snap stays on. If the wheel does nothing, a deferred viewport-sized scrollBy runs on a later frame - never in the same frame as the wheel, or you double-apply. If several impulses produce no DOM progress, I stop. A capped impulse count exists so a broken page cannot run forever.

That second driver is not “smarter linear scroll.” It is a different machine: wait → impulse → wait. Mixing it into the rAF pixel loop is how you get both snap fighting and random jumps.

Height is a liar in both directions

Lazy load grows scrollHeight after you “finished.” If stop is already armed, I do not cancel it - pages that keep appending forever never end. If we are still in the settle window, I unlock and continue. A small threshold ignores animation jitter that is not real growth.

Banners shrink the document. You can lock onto a ghost bottom, then sit there while the real footer is still off-screen. Unlock if we are no longer near the new bottom.

“Near the bottom” as a percentage fails on long pages. A few pixels of footer is a fraction of a percent and still missing. I use a tight pixel tolerance, then a stagnation filet: if we asked to move and scrollY did not, the browser may have hit a wall because height was overestimated (sticky chrome). One snap to max, then believe the wall.

Smart pacing - pause on headings, wait for in-view images to decode - is extra policy on top of this, not a replacement. It still needs a real document height. On a canvas-only scene it has nothing to attach to.

Blind pages: do not auto-stop

If the measurable scroll range is tiny compared to the viewport, I treat the page as blind. Constant speed, wheel events for the WebGL path, no automatic end.

The user hits Stop. That is not a missing feature. Auto-stop would cut a three-minute WebGL journey at second zero because maxScroll was 40 pixels.

Impulse mode uses the same blindness test: no “we reached the bottom,” because there is no bottom to trust. It still stops on no-progress or a max impulse count so a dead page cannot spin.

Cinema cannot save this. A map needs a height. A 40-pixel document produces a poster of the first screen, then a camera with nowhere to go.

What I will not pretend to drive

Cross-origin iframes are other documents. I do not inject into every frame. If the product lives in an embed, outer-page auto-scroll is theatre.

Horizontal overflow is a different axis. The driver is vertical.

A hidden tab can stop painting. Capture goes black. Scroll may still be “working” in a world you cannot see.

Overlay cleanup that hides fixed nodes must spare canvases, main landmarks, and near-fullscreen layers. Otherwise you “clean” the WebGL scene you came to record.

The series in one line

A screenshot is a scan. Live video is a compositor diary. Cinema is a camera on a poster. Auto-scroll is a negotiation with whoever actually owns the scroll.

I built ScrollFlow as that negotiation on the user’s machine. It still loses to iframes, hidden tabs, sideways pages, and scenes that never exposed a scrollbar. Those losses are the spec, not the backlog.

Feedback welcome

If a site ignored window.scrollTo, I want that engine.

I turned this experiment into ScrollFlow, a Chrome extension for creating local auto-scroll captures of websites. It is free to try, and I’d genuinely value feedback from developers who work with difficult pages.

A full-page PNG is a scan of viewports, not a screenshot of the document

Keny Alba — Mon, 31 Aug 2026 14:30:00 +0000

Why a single screenshot cannot exist

This is the fourth post in a series about capturing scrolling pages. Live video and Cinema maps get the attention. The still image is where sticky headers and the last slice quietly ruin the file.

I used to think “full page” meant one screenshot of a tall document. In a browser it means: scroll, wait, capture the visible tab, repeat, stack the bitmaps. Every step can disagree with the last.

captureVisibleTab sees the viewport. There is no API that returns the layout tree as one PNG at device resolution. Long pages are a loop.

Chrome also rate-limits how often you may call that API. The loop is slow on purpose. Racing it produces missing frames or errors, not a faster poster.

Between two captures the page is allowed to change: lazy images, sticky classes applied by JavaScript, banners collapsing, fonts swapping. A “full page” PNG is a timeline of viewports glued together. If you do not treat it that way, you debug the glue.

The last slice always overlaps - unless you crop

Suppose the page is not an integer number of viewports tall. You scroll by one viewport each time. On the last step, the browser clamps scrollTo. You cannot place the viewport so that its top sits on “the remaining pixels.” You land on totalHeight - viewportHeight.

The last bitmap therefore contains a band you already captured in the previous frame. Stack the images and the footer duplicates. I have seen copyright lines twice and a button that appears to sit on itself.

The fix is geometric, not aesthetic. Compute the remainder - the true height of the last segment - and crop the last bitmap to that band, in captured pixels, not CSS pixels. captureVisibleTab returns a device-pixel buffer. Remainder and viewport height are CSS. The crop uses the ratio bitmapHeight / viewportHeight or you cut the wrong amount on a retina display.

If the crop fails, I keep the raw last frame. A duplicated band is worse than a failed export, but a failed export is worse than a slightly messy PNG. The crop is non-blocking.

Frames cannot sit in the service worker as one giant message. Long pages used to die on memory and IPC size. Each viewport is written into the local encoder’s filesystem as it arrives. Assembly is a vertical stack at the end. The worker never holds the whole poster.

Cinema maps use this same capture family. A map that is too tall for a single raster (browser canvas limits are on the order of tens of thousands of pixels) must be refused before a multi-minute scan. Failure after the loop is the worst moment.

Sticky chrome is a stamp, not a header

A position: fixed bar exists in every viewport. If you stack raw captures, you print that bar at every height you visited. The page looks like it has a header every screen, because it did - on screen.

position: sticky is sneakier. At the top of the document it may still be in normal flow. Your first pass “find all fixed nodes” sees nothing. After the user (or your loop) scrolls, a script adds a class and the bar becomes fixed. Frame 0 is clean. Frames 1..N are tattooed.

The procedure that works:

At the top, mark nodes that are already fixed or sticky.
Capture frame 0 with the nav in its legitimate place.
Hide marked nodes with visibility: hidden, not display: none. Sticky elements still occupy flow until they stick. display: none reflows the layout you are measuring. visibility keeps geometry and stops the pixels.
After every later scroll, scan again for nodes that became fixed, mark them, wait a paint, then capture.

Hiding starts after the first frame. The first frame is the only one where a top nav is allowed to exist in the poster.

Scrollbars must be hidden for the whole scan. A scrollbar that appears and disappears changes the content width by a few pixels. vstack then misaligns columns. That is independent of any “clean UI” feature.

CSS transitions and scroll-triggered animation are frozen for the scan. A navbar mid-fade on a random frame is not a feature. Live video wants those animations. A poster does not. Different product, different freeze.

Lazy images in the current viewport get a short wait, then we continue. An unbounded wait is a hung capture. Black bands in the poster are the failure mode of not waiting at all.

Cleanup has to run even when capture fails

Injected styles, hidden sticky flags, and a forced scroll position must come off in finally. If the loop throws on frame 12, leaving cursor: none and frozen animations on the user’s tab is a bug they will remember longer than a missing PNG.

Window resize is not part of the historical PNG path. It is part of a Cinema map: the page must already be at output width so the bitmap aspect matches the video. A tall phone layout reflows; the map gets longer. That is why the height check exists before the loop, not after.

What a PNG is for

A stitched PNG is the right artifact when someone needs a layout audit, a mockup, or a still for a ticket. It is the wrong artifact when they needed motion, hover, or a playing video. Cinema is “this PNG, then a camera.” Live is “never this PNG.”

The header ghost and the doubled footer are not random quality issues. They are the scan model asserting itself. Once I named the last-slice clamp and the delayed fixed class, the glue became boring - which is what you want from glue.

The still export in ScrollFlow is that scan, cropped and destamped as far as the page will allow. Some overlays still win. The geometry does not.

Feedback welcome

If a stitched screenshot reprinted a header on you, I want that page.

I turned this experiment into ScrollFlow, a Chrome extension for creating local auto-scroll captures of websites. It is free to try, and I’d genuinely value feedback from developers who work with difficult pages.

The page and the encoder are different clocks

Keny Alba — Sat, 29 Aug 2026 14:30:00 +0000

Three times, one file

This is the third post in a series about auto-scroll capture. After choosing live versus a frozen map, the live path still has a quieter bug: my scroll loop, the compositor, and the video encoder do not share a clock.

I spent too long trying to force them into one number. The recordings got worse.

Auto-scroll in the page is a requestAnimationFrame loop. Each tick I compute a delta from real elapsed time, move the document, and hope the next paint includes that position.

The compositor produces frames on its own cadence. A 144 Hz display does not paint 144 unique page states into a capture. Tab capture samples what is on screen when it can.

The encoder then writes a compressed stream. For live WebM that stream is typically variable frame rate: one encoded frame per captured paint, not a metronome. Many players treat VFR as stutter. The file is still a more accurate diary of capture than a resampled clip that invented timestamps.

If I pretend these are one clock, I optimize the wrong layer.

Why I stopped smoothing the scroll delta

The speed presets are defined in “pixels per tick” at a notional 60 Hz. Real ticks are not 60 Hz. Under load - high resolution plus a live encoder - a frame callback can arrive late.

If I scale the scroll step by a large catch-up factor, the page teleports in a single paint. The encoder, if it captures that paint, stores a jump. The screen may have felt only a hitch. The file looks like a cut.

If I clamp catch-up too hard, the recording lags the intent of the speed preset. I chose a modest cap: better a slightly slower capture than a hundred-pixel jump in one frame.

I also tried an exponential moving average on dt. That made displacement even per painted frame and uneven in real time. Capture samples time, not frame index. A long frame that moves twice as far and stays on screen twice as long is the correct live motion. A smoothed dt made the page fall behind and then sprint. I removed the smoother.

Sub-pixel remainder matters here. Rounding every tiny step to an integer pixel creates a staircase that the encoder dutifully records. I carry the fraction and apply whole pixels when I have them. One scrollBy per paint. Never a catch-up burst of several steps in the same callback - that burst is one filmed jump.

Why I do not constrain capture frame rate

It is tempting to tell getUserMedia a maximum frame rate so the file matches a UI setting.

I tried it. On a high-refresh display, a forced period does not land on compositor beats. Chrome waits for the deadline, then takes the next paint. You skip two paints, then three, then two. Scroll advances in uneven steps for the entire take. That is the “page teleporting while I watch a smooth screen” failure, except now it is structural, not a load spike.

Without a frame-rate cap, capture follows content. Gaps between encoded frames match the compositor more closely. The UI can still offer a cadence for offline render and for transcode. Live capture does not get to fake that cadence at the sensor.

Software VP8 in the live recorder is CPU-bound. When pixel throughput is too high, the encoder drops input frames irregularly. The compositor is fine. The file is not. The fix that worked was reducing definition, not demanding a higher frame rate from a pipe that cannot carry it. A slightly softer image is easier to forgive than a slideshow labeled as 60 fps.

Bitrate has to follow real width × height × actual capture rate. Indexing bitrate on a quality label while encoding native retina resolution starves bits per pixel. The picture goes soft and the encoder is still drowning.

Encoding is a fourth clock, on the same machine

Service workers cannot run MediaRecorder. Capture and transcode live in an offscreen document. FFmpeg is bundled as WebAssembly. No remote encode.

Default live WebM is the recorder blob, VFR, download immediately. That is the file that matches the take.

A constant-frame-rate re-encode exists as a playback convenience. It is slower, generational, and can exhaust WASM’s 32-bit heap on large clips. I would rather ship the raw take than crash the export. If a container conversion fails, I keep the original recording under an honest extension (WebM or Matroska, not a lying .mp4 name).

GIF is a special case of the same memory physics. Building a palette from every source frame at full rate OOMs. I reduce temporal resolution before palette generation. A 4K request is not a 4K GIF if the WASM heap cannot hold it.

MP4 is fastest when the live recorder already produced H.264 and I can remux without a second encode. Full software x264 in WASM is a different, much slower job. Timeouts that assume “encode always finishes in N seconds” kill healthy long transcodes. An inactivity watchdog (no log, no progress) is the useful one. A ticker that pings “still working” forever hides a deadlock.

Cinema, from the previous post, is the escape hatch: an offline clock, frame / fps, hardware or WebCodecs encode, then a remux. It does not fix live VFR. It refuses the live time base.

What I would tell past me

Do not make scroll catch up to a late rAF with a huge step. The encoder will publish the lie.

Do not force capture frame rate to flatter a settings menu. You will alias the compositor.

Do not treat “1080p” as a promise about the live file. Treat it as a pixel budget and a bitrate, then tell the truth about VFR.

Local encode is the product constraint, not an implementation detail. The machine that showed the page is the machine that compresses it. When it cannot, a smaller honest file beats a crashed tab.

The live export in ScrollFlow is the compositor’s diary. The Cinema path is a score I conduct. Mixing the metaphors in one pipeline is how the stutter got “mysterious.”

Feedback welcome

If you have seen a smooth screen turn into a stuttering file, I want that case.

I turned this experiment into ScrollFlow, a Chrome extension for creating local auto-scroll captures of websites. It is free to try, and I’d genuinely value feedback from developers who work with difficult pages.

Live capture vs a frozen map: two honest ways to record a scrolling page

Keny Alba — Thu, 27 Aug 2026 14:30:00 +0000

This is the second post in a series about auto-scroll capture in a Chrome extension. The first post was the problem. This one is the fork I had to make: film the live tab, or render motion from a still image of the page.

They look similar in the UI. They are not the same product.

The same intent, two physics

I wanted a recording that moved down a site without my hand on the wheel. That sentence hides a choice.

Either the file is a recording of what the tab painted, in real time, while something else drives scroll.

Or the file is a reconstruction: capture the page once as a tall bitmap, then move a virtual camera across that bitmap on a clock I control.

Both are local. Nothing is sent to a render farm. They fail in opposite ways.

Live capture: the tab is the source of truth

Live capture uses Chrome’s tab recording path. Auto-scroll runs in the page. The encoder writes whatever the compositor put on screen.

If a video is playing, it is in the file. If a menu opens on hover, it is in the file. If a WebGL scene reacts to wheel input, that reaction is in the file. I am not inventing those pixels. I am sampling them.

That honesty has a cost. The encoder is bound to wall-clock time. It cannot pause the universe to finish a heavy frame. When the software video encoder is overloaded, Chrome does not slow the page down. It drops frames. The screen can still look smooth while the file becomes a slideshow.

Tab capture also has geometry quirks. It does not automatically mean “the quality label the user picked.” It films the tab in screen pixels, then fits that into a constraint box. A box with the wrong aspect ratio letterboxes the content: black bars that you will stitch into a map if you are not careful. I size the box from the tab’s real aspect and I never ask capture to upscale. Extra pixels are interpolation, paid for by the encoder.

The live scroller and the recorder are only loosely coupled. Prepare the page, start recording, then start scroll - except when I need the load animation, in which case the recorder must start before the reload. There is no shared frame index. Time in the file is “when the compositor happened to emit a frame,” not “tick N of my scroll loop.”

Cinema: the map is the source of truth

Cinema mode does the opposite. It builds a full-page still — the same family of problem as a stitched PNG — then treats that image as a set. A virtual camera has a position, a speed, an easing curve, and a shutter.

Because the page is a bitmap, I can sample several camera positions inside one output frame and average them. That is real motion blur: the integral of the shutter, not a directional smear guessed from velocity. Timing is frame index / fps. If I ask for a given cadence, I get that cadence. Dropped live frames are not part of this model.

The map’s aspect has to be the output’s aspect before capture. Format first, map second. If I resize the window after the map exists, zoom-1 no longer frames the page. The timeline of scroll positions can survive a recapture. The pixels cannot.

What the map cannot contain, the render cannot show. Hover that was never open. A <video> that was paused or never in view. WebGL that is a live scene, not a screenshot. CSS that animates on a timer rather than on scroll position. Cinema is precise about framing and rhythm. It is silent about anything that needs the page to keep running.

GIF export stays on the live path. Building a palette from a compositor-style render is a different, heavier job. I did not pretend Cinema could own every container.

How I choose

I treat this as a question about what must be true in the file.

If the demo is “this landing page has a looping hero and a scroll-triggered scene,” live is the only honest tool. Cinema would freeze the hero.

If the demo is “move down this article with a stable speed and a readable blur,” Cinema is the tool. Live will give me variable frame timing and whatever the encoder survived.

A stitched PNG is the third deliverable: no motion at all. It shares the map pipeline’s sticky-header problem, which is the next post. It does not share Cinema’s camera.

I do not blend the two in one file. A hybrid that “mostly” uses a map and “sometimes” samples the live tab would lie about both clocks.

What this does not solve

Live still cannot see into a cross-origin iframe. Cinema cannot either: the map is a screenshot of the outer page.

Live still goes black if the tab is hidden. Cinema’s map capture has the same constraint while the still is being taken, then the render is offline.

A page with no real scrollbar does not give Cinema a meaningful map height, and it does not give live auto-stop. That is a driving problem, not a compositing problem.

The useful discipline was naming the fork in the product, not hiding it. “Record the tab” and “render a camera over a poster” are both capture. They are not interchangeable.

If you ship site demos, the question is which lie you refuse: lost interactivity, or lost timing.

ScrollFlow keeps both engines on auto-scroll for that reason. I would rather the user pick an honest mode than get a file that looks fine and explains nothing.

https://bit.ly/try-scrollflow

How I built a browser extension that records a full web page while auto-scrolling

Keny Alba — Tue, 25 Aug 2026 15:03:26 +0000

Why a screenshot was not enough

I needed recordings of websites that moved the way a person would scroll them: a pause near a headline, a steady pass through a long article, a stop at the footer.

A full-page screenshot showed the layout. It did not show motion, hover, lazy-loaded blocks filling in, or the page-load sequence. It was a poster of the site, not a demo of using it.

A manual screen recording showed those things, and also my hand on the wheel. The speed was uneven. I skipped sections. The cursor wandered. A sticky header covered the title I meant to show.

That gap is why I built ScrollFlow as a Chrome extension. It drives the scroll itself and records on the user’s machine. It does not record every website correctly. The rest of this post is about why that is true.

A webpage is moving target

A webpage is not a PDF. While you travel down it, the document keeps changing.

Lazy-loaded images and extra sections arrive after you thought you had reached the bottom. A cookie banner or promo bar collapses, and the “bottom” you measured a second ago is no longer there. Sticky and fixed chrome sit in every viewport. If you stitch screenshots, that chrome stamps itself onto every slice.

Scroll-snap, smooth-scroll libraries, and custom overflow containers often ignore a simple “scroll to Y” command, or they fight it with their own animation loop. Canvas and WebGL scenes may have no real scrollbar at all, so the browser cannot tell you when the story is over.

Capture films what the tab is actually showing, not what your scroll function believes. If the encoder cannot keep up, frames disappear while the screen still looks smooth. If the tab is in the background, the recording can go black.

The hard problem is not calling scroll. It is keeping a changing document, a browser capture API, and an encoder honest about what landed in the file.

The approach: record live, render when needed

I did not send pages to a remote rendering backend. Recording and encoding run on the user’s device. The finished file downloads locally.

There are two ways to produce motion, and they answer different questions.

Live capture films the actual tab while auto-scroll runs. Animations, video, hover, and WebGL that are on screen appear in the file because they were really there. Timing is whatever the browser delivered that day. That is the path I use when the page is alive.

Cinema mode captures the page once as a still full-page map, then flies a virtual camera over that image. Timing is controlled. Motion can look deliberate because the “page” is a bitmap. Hover menus, playing video, and WebGL are not in that bitmap, so they cannot appear. I use this when I need a clean move down a mostly static layout.

A stitched full-page PNG is still useful when a still is the deliverable. It is a scan of viewports, with sticky chrome handled as a special case, not a screenshot of the whole document object.

Exports stay on the machine: the live recording, a local conversion when a different container is needed, or a composited file from the map. If a conversion fails, the capture is not thrown away.

Where browser automation gets difficult

Four cases ate most of the work.

Lazy-loaded content lies about height. Auto-scroll can hit a fake bottom, notice that the document grew, and continue. It can also unlock if a banner collapsed and the real bottom moved. Infinite feeds and images that arrive late still surprise it. There is no complete answer, only a better guess than stopping on the first pause.

Sticky and fixed UI reprints itself. For a full-page image I keep the header on the first slice and hide it on the rest, then look again after each step. Many navs are ordinary until you scroll, then they become fixed. Overlay cleanup hides chrome without deleting nodes, and it still guesses wrong on some widgets.

Scroll-snap and custom scroll engines fight linear motion. Pixel-by-pixel scrolling on a snapped marketing site looks like the page is arguing with you. Ordinary auto-scroll turns snap off. A stepped, impulse-style move leaves snap on, because those sites use it as the section cut. Smooth-scroll libraries remember an old position and restore it after you jump to the top, so the start of a capture has to hold the page there until they settle. Overflow boxes that actually own the scroll need extra handling. Some pages still win.

Canvas, WebGL, and dynamically rendered scenes often have no usable scrollbar. If the document barely scrolls, I keep moving at a constant speed and I do not auto-stop. The user has to end the recording. That is the honest outcome for a scene that never exposed a height. Cinema mode cannot invent a running canvas from a still map.

What I learned

I learned four things I wish I had believed on day one.

A screenshot and a recording are different products. Freezing animation and hiding sticky chrome is correct for a poster and wrong for a scroll-driven demo.
The page, the compositor, and the encoder are three clocks. Forcing them into one number made the video look worse than accepting what the live tab actually produced.
Local encoding is a feature and a limit. Work stays on the device. Heavy conversions can fail, so a lesser local file is better than a crashed export.
Browser APIs dominate the design. A background script cannot record media. A side panel does not grant tab access the way a toolbar popup does. Hidden tabs go black. Those constraints decided the architecture more than any UI idea.

What still breaks

Cross-origin iframes are a separate document. If the real page lives in a frame, auto-scroll may move the wrong thing or nothing useful.

If you switch away from the tab, the capture can go black. There is a warning. There is no recovery.

Horizontal pages are out of scope. The driver moves on the vertical axis.

Complex WebGL and custom-scroll scenes with no real scrollbar do not auto-finish. You stop them by hand. Cinema mode will not reconstruct hover, video, or a running canvas from a frozen map.

I do not claim this works on every website. The difficult pages are why the work exists.

Feedback welcome

If you have fought sticky headers in stitched screenshots, custom scroll fighting a programmatic move, or a recording that does not match what you saw on screen, I want those cases.

I turned this experiment into ScrollFlow, a Chrome extension for creating local auto-scroll captures of websites. It is free to try, and I’d genuinely value feedback from developers who work with difficult pages.