Voice follow - a voice-controlled teleprompter

What voice follow does

Voice follow listens while you read and moves the script to keep up. Slow down and it slows. Stop to answer a question and it stops. Pick the sentence up again and it carries on from there.

It is off when the page loads, and it stays off until you press the microphone button in the dock. Nothing listens before that, and turning it on is the moment your browser asks you for the microphone. There is no dialog of ours in front of that one, because the switch is already you asking for the feature.

What moves the script is a match, not a volume level. It takes the last few words it heard, finds them among the words just ahead of the reading line, and moves the script to where they landed. Speech that is not in the script leaves the script where it is: a cough, an aside to whoever is holding the light, a word the recogniser got wrong. It waits rather than lurching.

Where your audio goes

The speech recognition is your browser's, not ours. Depending on which browser you are in, your audio either stays on your machine or goes to that browser's vendor to be turned into text. The line beside the switch says which of the two you are on before you enable anything. On the first path it reads:

Speech recognition runs on your device. Audio isn't uploaded.

On the second:

Your browser can't run speech recognition on-device. Turning this on sends audio to your browser vendor for transcription.

Where the browser can recognise speech on the device, this asks it to. The first time you switch voice follow on, that can mean downloading a language pack; once the pack is installed, recognition happens on your machine. Where the browser cannot, which today means Safari and iOS, the audio goes to the browser vendor for transcription under that vendor's terms.

Either way we do not receive, store, or forward your audio. We are not in that path at all. Your microphone talks to your browser, and your browser hands us text.

That line sits beside the switch permanently because nothing else says it. Your browser's permission prompt asks whether a site may use the microphone. It does not say where the audio goes afterwards, and Apple's own guidance puts the job of explaining that on the site rather than on the system.

Two sentences we will not write, because on some browsers they are false: recognition here is not always local, and voice follow is not always usable offline. Both are true on the on-device path once its language pack has downloaded. Neither is true on the vendor path, where the transcribing happens somewhere else and needs a connection to get there.

Which browsers can do it

As of 27 August 2026:

• Chrome, desktop and Android, works. Recognition has been there behind a prefix since Chrome 25, and since Chrome 139 it can run on the device, which is the path this asks for first.
• Safari works on Mac since 14.1 and on iOS since 14.5, on the vendor path. Whether Apple transcribes on the device or on a server depends on the device and its settings, and a website cannot see which of those is happening, so this page does not claim to know.
• Edge has the interface and is unreliable with it. It commonly fails the moment recognition starts, whatever language you ask for. When that happens the script goes back to a fixed speed and says so.
• Firefox, desktop and Android, does not make it available to websites. It has shipped switched off since version 22.
• Opera does not support it.
• Samsung Internet has supported it since version 4.

caniuse puts speech recognition at 87.55% of global browser usage, counting partial support. Two of the holes in that number matter here: Firefox, and whichever Edge you happen to be in.

We are not going to tell you that every modern browser supports this. One of the big ones does not, and the first person to open this page in Firefox could say so.

The vendor path also needs a connection to work at all. Only the on-device path runs offline, and only once its language pack has downloaded.

What happens when it cannot

Three states, not two.

It works. The switch is there and off. You turn it on, your browser asks for the microphone, you decide.

It cannot work here. The button stays where it is, marked unavailable, with a line under it saying this browser cannot do speech recognition and the script will roll at a fixed speed instead. We do not hide the button. A page that describes a feature you then cannot find anywhere in the product has spent your visit on a promise it never meant to keep. The unavailable button is still reachable by keyboard and still takes a focus ring, and the line explaining it is attached to the button rather than floating near it, so a screen reader gets the explanation along with the control.

It broke while running. Recognition can be present and still fail at the moment it starts. Edge does this routinely, and a declined microphone or a dropped connection will do it anywhere. Voice follow switches itself off, the fixed-speed roll takes over, and the dock says the script is back to a fixed speed. It announces that out loud rather than only changing a colour, because at that moment you are looking at the reading line, not at the dock.

That third state is why asking the browser whether it has the feature is not enough on its own. Edge answers yes and then fails, so the failure has to be caught where it happens and answered with something you can see.

Which language it listens in

Voice follow asks the recogniser for the language the page is in, and asks your browser at that moment whether it can do that language, rather than looking it up in a list we keep. Chrome publishes no list of the languages its recogniser supports, and the set of languages with on-device models changes without notice. A table in our code would be out of date within months, and wrong with confidence.

Two lists get mixed up here. The languages this site's interface is available in, and the languages your browser can transcribe, come from different places and are not the same set. Neither one tells you the other.

Whether you need it at all

Most reading does not need it. A fixed speed set to your own words per minute is the main path here, and the prompter is built around that. Voice follow earns its place when the pace is not yours to set: an interview where somebody interrupts, a demo where you wait for a build to finish, a take where you stop to move a light and start the paragraph again.

It costs something too. It wants a microphone, a room quiet enough for your browser's recogniser, and on most browsers a connection. A fixed speed wants none of those, and both the duration on the stage and the script timer come from it.

This is not a rare feature, either. As of 27 August 2026, VoicePrompter and SolPrompter both follow your voice free and without a signup. What is particular about this one is narrower and checkable: it is off until you ask for it, it takes the on-device path wherever the browser offers one, it tells you which path you are on before you turn it on, and it says out loud when it has given up.

Questions

Does it work in Firefox? No. Firefox does not make speech recognition available to websites. The prompter still works there; the script rolls at a fixed speed.

Does my voice get uploaded? It depends on your browser, which is why the switch says so before you turn it on. On browsers that can recognise speech on the device, the audio stays on the device. On Safari and iOS it goes to the browser vendor for transcription. We never receive it.

Do I have to allow the microphone? Yes. Voice follow cannot hear you otherwise. Declining is a normal answer, and it leaves the script on a fixed speed.

Does it record anything? No. Nothing here records audio or video. The recogniser turns speech into text and the text moves the script.

What happens if it stops mid-take? The script goes back to the speed you set and the dock says so, so you do not have to work it out yourself.