Yes, a browser-based teleprompter can work offline: TellyPrompter installs as a web app, and after one online visit the prompter itself — scripts, scrolling, recording — runs with no connection at all. The catch is the phrase "after one online visit", and knowing exactly what needs the network once, what never needs it again, and what always will is the difference between a shoot that runs and a shoot spent waving a phone at the ceiling.
This piece explains how offline works for a web app, what still functions with no signal, what doesn't, and the five-minute preparation that makes the question irrelevant by the time you're on location.
The room with bad wifi is a normal room
Shoot locations are chosen for light, quiet and backdrop — never for signal. The spare room at the back of the house, the borrowed office at the weekend, the village hall, the car park where the light is good at four o'clock: these are ordinary places to record, and they are reliably terrible places to be online.
A teleprompter has a particular relationship with this problem, because it fails at the worst possible moment. You're set up, lit, framed and settled, and the tool that holds your script won't load. Most software treats connectivity as a given; a prompter built for real shoots has to treat its absence as the normal case. That assumption shaped TellyPrompter from the start — the first requirement was opening in a room with bad wifi, which is why the whole app is small enough to arrive on a weak connection and structured to stop needing one.
What "offline" means for a web app
A website that works offline sounds like a contradiction, so here's the actual mechanism, briefly.
Modern browsers support two things that together make it real. The first is installation: a progressive web app (PWA) can be added to your home screen or desktop from the browser — no app store — after which it opens full-screen like any installed app. The second is a service worker: a small programme the site leaves behind in your browser, which stores the app's files locally and serves them itself. Once it's in place, opening the app doesn't fetch anything; the copy on your device loads, connection or none.
The one structural consequence: the first visit must be online. The service worker and the app's files have to arrive over the network once before they can be served locally. There's no way around that first fetch — which is why the preparation section below exists, and why the golden rule is simple: first visit at home, every visit after that anywhere.
Your scripts, meanwhile, live in the browser's local storage on the device — they were never on a server to begin with, so the library is as offline as the app is.
What works with no network, and what doesn't
Works offline, once installed:
- Opening the app and your whole script library — pasting new scripts, editing, tagging
- All three scroll modes. Constant and sound-level scrolling have no network involvement at all; voice-following uses the browser's on-device recognition — speech recognition runs on the device and the audio is never uploaded — so there's no server in the loop to lose. (Recognition itself remains the browser's: quality varies by platform and language, and Firefox doesn't provide it at all, connection or none.)
- Mirror mode, rotation, and every display setting — all stored on the device
- In-app recording. The camera, the microphone and the file are all local; a take recorded in a field is written the same as a take recorded on fibre
- Caption export (SRT/VTT) and script export — generated on the device from data on the device
Needs the network:
- The first visit, as above — and after an update ships, an online open picks up the new version, but a stale offline copy keeps working in the meantime
- Google Docs import. Fetching a document is a network request by nature. Import the doc while you're connected and it's in your library; the library needs nothing thereafter
- File import from cloud storage — a .docx in your email or drive needs downloading first, though a file already on the device imports fine offline
- Account and sync features. Signing in and Pro's cross-device library sync talk to a server, so a lapsed connection defers sync until you're back online — the local library carries on regardless
The pattern is deliberate: everything on the path from script to take is local, and the network-touching features are the ones that fetch from or push to somewhere else by definition.
The prepare-before-you-go checklist
Five minutes at home removes every failure mode above:
- Install the app — open TellyPrompter in the browser and add it to your home screen or desktop. This is the step that plants the offline copy.
- Load every script for the shoot. Paste them, or run any Google Docs imports now, while the network exists. Tag them for the session so they're one tap apart on the day.
- Open the app once from its icon and confirm the scripts are there. You've just rehearsed the exact thing you'll do on location.
- Test the mic and camera once — grant the permissions at home, not standing at your mark.
- Airplane-mode dress rehearsal. Turn the connection off, open the app, start a take, read a paragraph. Thirty seconds, and the question "will this work out there?" is answered empirically rather than hopefully.
That last step is the one people skip and the one worth keeping: it converts every claim in this article into something you've watched happen on your own device.
Degrade, never block
The design principle underneath all of this is worth stating, because it's checkable against behaviour: losing a capability should remove that capability, and nothing else.
No network takes away imports and sync, and leaves a complete prompter. No speech recognition — Firefox, or an unsupported language — takes away voice-following, and leaves two other scroll modes. No camera permission takes away recording, and leaves the prompter. No microphone takes away voice mode and recording sound, and the constant scroll still runs. At every step the answer to "can I still do the take?" is yes, with one fewer convenience.
That's the property that matters on a shoot day, more than any single feature: the tool's failure modes are subtractions, not stoppages. The room with bad wifi stops being a risk you plan around and becomes just a room — which, given how shoots choose their rooms, is exactly as it should be. If the software half of your rig is still an open question, voice-following vs constant scroll covers the other decision that shapes the day.