On the free-first-session offer, complete your first session free and continue with Pro. Existing Free users and visitors on the earlier offer keep their ongoing Free access. See the current web offers.
TellyPrompter can support offline prompting and recording when the required app files and scripts are available locally. An online visit alone is not a guarantee: browser storage can be cleared or evicted, and speech recognition may still need a connection. Prepare the app online, then test the intended workflow with the network off before a shoot.
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. When the required files have been cached and retained, the service worker can load the local copy without a connection. Missing or evicted files can prevent that.
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: prepare at home, then verify the local copy before each offline shoot.
Scripts saved locally remain on that device while browser storage is retained. A signed-in account can also sync scripts: Free allows five and Pro an unlimited account library. Syncing does not make a script available offline until it has reached the device. See the current library limits.
What works with no network, and what doesn't
Local features to check before going offline:
- Opening the cached app and the scripts stored on this device — pasting new scripts, editing, tagging
- Constant and sound-level scrolling, which have no network involvement whatsoever. Voice-following is the one to check before you rely on it: it uses the browser's own speech recognition, and only some browsers run that on the device — see "Needs the network" below. (Recognition is the browser's either way: 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. Capture is local, but still needs browser support, permissions and sufficient device storage. Review and download a test recording before leaving
- Script export is Free and generated locally. Prepared SRT/VTT caption export is included in the complete free first session and with Pro, and depends on available timing. Check that your session or Pro access and the required take data are available on the device before relying on offline export.
Needs the network:
- The first visit, as above — and after an update ships, an online open picks up the new version, but a retained offline copy may remain usable in the meantime; test before relying on it
- 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; keep the imported script available locally and confirm it opens offline
- 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, script sync and recording uploads through Save to account need a connection. Free accounts sync five scripts; Pro has an unlimited account library. Locally available scripts can still be used. Recording storage is 1 GB per account and 250 MB per recording on both plans; Pro does not increase it. See account limits and privacy.
- Remote speech recognition. Browser speech recognition can use a network service. Local recognition requires browser support and an available language pack; the app selects it only when available. Test your exact browser and language offline. Constant scrolling is an alternative, while sound-level scrolling also needs microphone permission. See MDN on browser recognition and local processing.
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. Voice-following is the honest exception, because the recogniser belongs to the browser rather than to us.
The prepare-before-you-go checklist
Before relying on an offline session:
- Install the app — open TellyPrompter in the browser and add it to your home screen or desktop. Allow the app to finish loading; installation alone does not prove every required file is cached.
- 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. Check the remaining workflow after a failure; a usable recording still depends on browser support, permissions and storage.
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.