Caption Extension Privacy: Where Your Tab Audio Actually Goes (2026)
Every caption extension says it doesn't store your audio. That sentence is doing a lot of work, and you have no way to check it. Here is the whole path instead — what leaves the tab, in what pieces, who receives it, and what is actually written down.
Search for a caption extension and you will find the same line on every product page: we do not store your audio. It is almost certainly true of most of them. It is also unfalsifiable from the outside — the claim is about a server you cannot inspect, made by the party that benefits from you believing it.
This article takes the opposite approach. Instead of a promise, it walks the data path step by step, names every hop, says which parts are written down and which are not, and then tells you how to watch it happen yourself in about five minutes.
It is about the extension we make, so read it with that in mind. But the mechanics are the same for every audio-capturing caption tool on the market, because there is only one way to build one, and the checklist at the end works on any of them.
The uncomfortable part, stated plainly
If a caption extension is transcribing what it hears, and it is not running the speech model on your laptop, then your audio leaves the machine. There is no architecture in which it does not. Running Whisper locally is possible — whisper.cpp does it well — but doing it live, per tab, inside a browser extension, fast enough to keep up with a video, is not what any shipping product in this category does.
So "does my audio leave?" is the wrong question, because the answer is always yes. The useful questions are: in what pieces, to whom, for how long, and what is written down afterwards. Those four have real answers, and they differ between products.
The path, step by step
This is what happens between pressing the button and seeing a subtitle, in the order it happens.
- You ask for one specific tab. The extension never receives a microphone stream and never sees the whole browser — it asks Chrome for the audio of the tab you are looking at. In our case the popup reads that tab's URL only to check it is a normal
http/httpspage, and passes on nothing but the tab's numeric id. - Chrome mints a single-use stream id for that tab. The background worker calls
chrome.tabCapture.getMediaStreamId, and the id is redeemable exactly once, by this extension's own hidden document. No other page can spend it. - The captured tab goes silent, which is why you hear a click. Chrome mutes a tab whose audio it has handed over; the extension plays the stream straight back out through an audio element so you still hear the video. That tiny gap and the volume blip are this handover, not a bug.
- The audio is downsampled and cut into pieces. It is converted to 16 kHz mono — the rate speech models want — and sliced on silence: roughly half a second of quiet ends a piece, no piece is shorter than a second, and nothing is allowed to grow past 15 seconds. That cap is the single most useful number on this page, because it is an upper bound on how much audio can exist in one request.
- Each piece goes to our server, and only ours. In the standard mode a piece is uploaded to our own endpoint; in the real-time mode roughly 300-millisecond frames stream over a single WebSocket to the same place. Either way the destination is one hostname: our API. There is no direct connection from your browser to a speech provider, and no third-party analytics host in the path.
- The server passes it to a model and gets text back. It does not write the audio anywhere first. The handler takes the bytes, encodes them for the inference call, and returns the transcript. Our deployment has no object-storage binding at all — there is no bucket configured that audio could be written to, which is a stronger statement than a policy promising not to.
- Two different providers, depending on mode. Standard mode uses Whisper running on Cloudflare's inference platform. Real-time mode streams to Soniox, a US speech provider, which returns transcript and translation in one pass. Both are named in our privacy policy because you deserve to know which one your audio reached.
- The text goes to a translator, then back to the tab. In standard mode each line is sent to a translation model and the translation streams back. It is drawn in an overlay, and it lives in an array in that page's memory — capped at five thousand entries, emptied when you stop. Nothing about it is saved to storage.
What is written down, and for how long
This is the part the marketing line "we don't store your audio" hides. Something is stored — accounts, counters, session records — and the honest version of the claim is a table, not a sentence.
| What | Where it lives, how long | Contains speech? |
|---|---|---|
| Audio chunks | In transit, in memory — milliseconds | Yes — never written down |
| Transcript | That tab's memory — until you stop | Yes — on your machine only |
| Session record | Our database — until you delete the account | No — start, end, duration, language pair |
| Usage counter | Key-value store — until the period rolls over | No — a number of seconds |
| Account | Our database — until you delete it | No |
| IP address | Rate limiter — about 25 hours | No — for rate limiting |
| Device signal | A one-way hash — for the trial counter | No — the inputs never leave your device |
| Page URLs, history | Not collected | No |
Two rows deserve a note. The session record is real and it is new information to most people: when you stop a session, we record that it happened, how long it ran, and which language pair you used — never the content. It exists so we can tell whether a feature is used at all. And the transcript is the one thing on this list that does contain what was said, and it never leaves the tab except as the individual lines being translated.
The four objections people actually raise
"So you do have my audio on a server."
It passes through, yes. Saying otherwise would be a lie, and any product that claims its audio never reaches a server while also transcribing it in real time is either running a local model or not telling you the truth. The meaningful distinction is passes through versus is kept: the request holds the audio for the length of one inference call, and then the buffer is unreachable. The exposure is the trip, not a copy in a drawer.
"What about a call I'm on?"
This one is not a technical question and no extension can settle it for you. In many places, captioning a conversation you are part of is fine while recording it is not, and the line between the two is drawn differently by jurisdiction. Our side of it is that audio is processed in real time and discarded. Your side of it is that the other person may still object to being transcribed, and that consent is yours to obtain. We wrote about that specifically for meetings and calls, because it comes up more there than anywhere else.
"How would I know you're not lying?"
You can watch it. Open chrome://extensions, find the extension, and look for its inspectable views while a session is running — the hidden document that holds the audio appears there. Open the Network tab on it and you will see the requests as they go: one hostname, one request per audio piece, and a body you can measure against the fifteen-second cap. If a tool is quietly shipping your audio somewhere else, that panel is where it shows up. It is also where you can confirm the absence of an analytics SDK, which is the quieter risk in this category — the audio claim gets all the attention, while the tracking library rides along unmentioned.
"What if the audio contains something sensitive?"
Then the honest framing is that you have handed a third party a recording of it for the duration of one request. A therapy session, a medical consultation, a union meeting: the model provider processes that audio, even if only for a moment, and even if nothing is retained. Our privacy policy addresses this directly, because audio captured this way can incidentally contain health, religious, or political content. If a moment of third-party processing is unacceptable for what you are about to play, the next section is for you.
The only way to keep the audio on the device
There is one mainstream option that never sends audio anywhere: the captioning built into Chrome itself. Its speech model runs on your machine, which is why it works with the network off and why the audio never becomes a request. That is a genuine advantage, and for some people it settles the question entirely.
It also comes with the constraints that follow from running on-device: a fixed list of about twenty recognised spoken languages, one caption stream at a time with no original-and-translation pairing, no history to scroll back through, and no way to copy a line. So the trade is unusually clean — if "nothing leaves this machine" is a hard requirement, the built-in captions are the only answer, and you accept the shape. If you need the second language or the transcript, the audio has to travel, and then the only question left is who receives it and what they keep.
What to check in any extension, including ours
- Does the policy name its providers? "Third-party services" is not a disclosure. The policy should name the speech provider, the translation provider, and where they are.
- Does the extension ask for permissions it doesn't use? Every permission is a capability, and a caption extension should be able to say what each one is for. Ours asks for seven, and they map to seven jobs: capture the tab's audio; save your settings; run a hidden page that has to exist to hold the stream while the tab sits in the background; act on the page you clicked, and inject the overlay into it; keep a timer for the long-session auto-pause and the usage warning; and read your sign-in state. There is no host permission at all — access to a site is granted the moment you click, for that one tab. The widest of the seven, and the one Chrome turns into an install-time warning, is the audio capture.
- Does it ship analytics? Then your audio claim is only half the story.
- Can you watch the network? If the extension's hidden pages are not inspectable, or the traffic obviously goes somewhere unrelated to the vendor, that is your answer.
- Can you delete what it kept? Account deletion should remove the account, the session records, and the subscription data. If there is no such path, the retention table is not a table, it is permanent.
One disclosure in that spirit, since you are being asked to trust a checklist: our marketing site loads a Reddit conversion pixel on article pages like this one. The extension itself ships no analytics of any kind. Both facts are in the privacy policy, and the distinction between the website and the extension is exactly the kind of thing worth checking in anyone's product.
Bottom line
A caption extension that transcribes in real time sends your audio to a server. The useful questions are how much at a time, to whom, and what survives the trip — and those have specific, checkable answers: fifteen-second ceiling, one hostname, two named providers, no storage bucket, nothing written down but a duration and a language pair.
If you would rather nothing left the machine at all, use Chrome's built-in captions and accept one language at a time. If you want the translation or the transcript, Tablingo is the one we make, and this page is the description of what it does with your audio. The mechanism behind the whole category is in a companion piece.