Teleprompter software scrolls in one of two fundamental ways: at a constant speed you set before the take, or by following your voice — listening to the words you say and keeping the script in step with them. A voice-following teleprompter has no scroll speed of its own; the read sets the pace, so pauses, ad-libs and skipped lines don't cost you your place. Which one you want depends on the job, and this piece lays both out honestly, including the halfway house between them and the things voice-following genuinely cannot do.
Constant scroll: performing to a number
A constant-scroll prompter asks you to set a speed — words per minute, or a slider — and then moves the text at that speed from start to finish. It's the traditional design, inherited from broadcast, where a dedicated operator rides the speed control by hand while the presenter reads.
Solo, there's no operator, so the number you guessed before the take is the operator. Speak slower than the guess and the text creeps ahead; pause, and the pause spends your margin; ad-lib, and the script has moved on by the time you return; stumble, and you're deciding mid-sentence whether to chase the text or stop the take. The speaker ends up doing two jobs — saying the words and tracking their position against a moving surface — and the second job is what audiences hear as a wooden read.
To be fair to the design: constant scroll has real virtues. It's utterly predictable. It works in any browser, with no microphone, in a noisy room, in silence. A rehearsed presenter who knows their pace can lock a speed and ride it, the way newsreaders do, and for read-along or timed-to-music material a fixed pace is precisely the point. The costs only appear when the read is meant to sound like natural speech, because natural speech doesn't have one speed.
Sound-level scroll: the halfway house
Between the two sits sound-level scrolling: the software advances the text while the microphone hears speech and pauses when you go quiet. It knows that you're talking, but not what you're saying.
That single fact defines both what it fixes and where it breaks. Pauses now work — stop talking and the script stops with you, which removes constant scroll's worst failure. But because it can't match words, it's still moving at a preset rate whenever sound is present, so the drift problem returns in miniature: talk faster than the rate and you catch the text up, slower and it pulls ahead. Ad-libbing advances the script even though you've left it, since your aside is just more sound. And anything else the microphone hears — a passing lorry, a cough — reads as speech.
It's a genuine improvement for a steady reader in a quiet room who mainly needs pauses respected, and it's the right fallback where full recognition isn't available. It's not the same thing as being followed.
Voice-following: the page keeps your place
A voice-following teleprompter listens to the words themselves. Speech recognition transcribes what you're saying, the software matches it against the script, and a highlight sits on the word you're actually speaking. The scroll is a consequence of the match: the text moves because you've moved through it.
What that changes, concretely:
- Pauses are free. Stop to think for ten seconds; the highlight waits on your word.
- Ad-libs are free. Wander off script for an aside and nothing moves; when a phrase from the script comes back out of your mouth, the highlight picks you up where you resumed.
- Skipped lines don't strand you. Decide against a paragraph mid-take and jump past it; the match follows you to where you actually went.
- Backtracking works. Retake a sentence you fluffed and the highlight goes back with you.
- Pace variation is the point, not a problem. Rush the setup, slow into the payoff — the scroll does the same, because it has no opinion about speed.
The practical consequence is that the second job disappears. There's no position to track against a moving surface, because your position is wherever you are. This is what TellyPrompter does, and it's the difference the whole product is built around: scroll speed is the read, not a setting.
What voice-following cannot do
Honesty section, because the technology has real edges.
Recognition quality belongs to the browser, not the prompter. Voice-following in a web app is built on the browser's speech recognition. That engine cannot be tuned by the software using it, and its accuracy varies by platform, by language and by microphone. A language the engine handles poorly, or a very echoey room, degrades the following — the practical test is always the same: paste a real script and read a paragraph aloud.
Firefox doesn't implement it at all. Firefox has no Web Speech API, so voice-following isn't available there — no prompter running in Firefox can offer it. In TellyPrompter, everything else still works in Firefox, and the constant and sound-level modes still scroll; the product degrades rather than blocking. But the listening mode needs a browser that can listen.
It follows a script; it doesn't take dictation. The match needs written words to match against. Fully improvised speech has nothing to follow — though that's not a prompting job in the first place.
Heavy departures take a moment to re-match. Return from a long ad-lib mid-way through a paragraph you never started, and the software needs a phrase or so of script-matching speech to lock back on. In practice you notice this as a beat, not a failure — but it isn't telepathy.
On-device recognition and the microphone question
A teleprompter that listens raises an immediate and fair question: where does the audio go?
For TellyPrompter, the answer is the one sentence that can be said without qualification: speech recognition runs on the device and the audio is never uploaded. The matching happens where the microphone is; there is no server transcribing your takes.
If you're evaluating other voice-following software, it's worth asking the same question directly, because architectures differ — some products do send audio to a server for recognition, which may be a perfectly acceptable trade for you, but it's one you should get to make knowingly, especially for unreleased or client material.
Which to choose for which job
Choose constant scroll when the read is rehearsed and paced — you know your speed and can hold it; when the material is timed to something external, like music or a broadcast slot; when you're in Firefox or a browser without recognition; or when the room is too loud or the language too poorly supported for the match to hold.
Choose sound-level when you mainly need pauses respected, the room is quiet, and full recognition isn't available or isn't holding.
Choose voice-following when the read should sound like natural speech — which for a solo creator recording themselves to camera is nearly always. Pauses, ad-libs, retakes and nerves are the normal texture of that work, and this is the mode that treats them as normal rather than as errors. It's also the mode that changes what a script is: less a track to stay on, more a floor to come back to.
The good news is that this isn't a purchase decision, it's a toggle. TellyPrompter includes all three modes on the free tier, so the honest way to settle it is empirical: same script, one read in each mode, including one deliberate pause and one deliberate ad-lib. The mode that kept your place through both — and left your attention free for the lens — is the answer. For what to do with that freed attention, see how to read a teleprompter without sounding wooden.