A screen recorder samples whatever the display showed. A renderer computes each frame. The difference decides whether you can reproduce your own work.
Record your screen twice, doing the same thing, and you get two different files. Not slightly different — different frame timings, different dropped frames, a different result on a busy machine than on an idle one.
Most of the time nobody notices, because most screen recordings are watched once. It starts to matter the moment you need the same output twice.
What a recorder actually does
A screen recorder samples. It asks the display what it is showing, as often as it can manage, and writes down what it got. The rate it manages depends on what else the machine is doing: another app waking up, a browser reflowing, a background index running.
So the output is a record of conditions as much as content. Two recordings differ because the two moments differed, and there is no setting that makes a sampled capture reproducible, because sampling is the thing that made it unreproducible.
What a renderer does instead
A deterministic render does not ask what is on screen. It computes frame N from the state at frame N — for a scroll, that is a scroll position derived from the frame number and the motion curve, with no reference to the wall clock at all.
Frame 200 of a 600-frame scroll is the page at exactly one third of the way down the easing curve. It is that on a laptop on battery. It is that on a Mac Studio. It is that today and next month.
The same input produces the same bytes. Not similar bytes — the same ones.
What that buys you in practice
Re-export without re-deciding
Someone asks for the same video at 9:16 instead of 16:9. Change the ratio, export again, and everything else is identical — same timing, same easing, same pauses. With a recording you would perform it again and get a different take.
Fix the source, keep the take
A typo on the page. Fix it, re-render, and you have your video back with the typo gone and nothing else changed. This is the one that saves an afternoon.
It cannot drop a frame
A dropped frame is a sampling failure — the recorder asked and the machine was busy. A renderer is not asking. Every frame is computed, so every frame exists, including on the machine that is also compiling something.
Your machine's speed changes only how long it takes
A faster Mac finishes sooner. It does not produce a smoother file, because the file was never a function of speed.
When you want the recorder anyway
Determinism has a cost: it can only render what it can compute. A scroll is computable. A hover state, a menu opening under a cursor, a form being filled in — those are performances, and they need a hand on them.
That is why Capture site has both. Scroll mode renders; Record mode records the live view while you drive it. Record is not reproducible and cannot be, and using it for a plain scroll would trade away the one property worth having.
The short version
If the output is a scroll, render it. If the output is an interaction, record it. The mistake is recording something that could have been rendered, and then needing it again.