Subtitle Tracks vs. Audio Capture: How Caption Tools Actually Work (2026)
Two completely different technologies sit behind the words "subtitle extension", and they decide where a tool works long before you install it. Here is how to tell which road yours is on.
Two extensions, both advertised as "real-time subtitles for any video". One of them captions a Korean livestream that has no subtitles at all. The other shows nothing on that same stream — and nothing on a webinar recording, and nothing on a documentary with the text printed into the picture. Yet on a Netflix original, the second one produces a cleaner result than the first ever does.
That is not a quality gap, and it is not a bug. It is two different technologies reading from two different inputs, and the difference is settled before you install anything. Once you know which road a tool is built on, you can predict where it will work and where it will sit there showing nothing.
The only question that matters: where does the text come from?
Every caption tool has to obtain text, and there are exactly two places to get it. Either it reads text that already exists — in the page, in the player, or in the platform's own delivery — or it turns sound into text itself.
Those are the two roads. Nearly every practical difference between these products follows from that single choice, including the ones nobody puts in the feature list.
Road one: read the track that is already there
Most video on the web travels with text attached. An HTML5 video element accepts a <track> element pointing at a WebVTT file. YouTube publishes timed captions, both uploaded and auto-generated. Streaming services deliver timed text alongside the video. Some players draw captions into the page as ordinary elements, which means the text is simply sitting in the DOM.
A track-reading tool does one job: it takes that text and renders it its own way. The dual-subtitle extensions people recommend for Netflix are all on this road, and they are extremely good at it — that is not faint praise, it is the correct tool for the job it does.
What this road gets right
- Latency of nothing. The text is already timed, to the millisecond, by a person or by the platform. There is no model in the loop, so there is nothing to wait for. Pause, seek, scrub: the captions are correct on the next frame.
- The platform's spelling, not a model's guess. Character names, brand names, invented vocabulary, medical terms, non-English proper nouns — a human typed them, so they come out right. This is the one place where a track reader is not merely faster but genuinely more accurate than anything that listens.
- Two tracks at once, properly. If the platform ships Japanese and Spanish, a track reader can render both simultaneously, with per-line dictionary lookup if it is built for language learners.
- Almost no running cost. Reading a string and drawing it on a page costs nothing per minute. That is why this category can be generous and cheap at the same time, and why it existed long before speech recognition got good.
Where it stops dead
Every failure mode here is the same failure: the input is not there.
- No track, no text. A Twitch stream, a live webinar, a company all-hands, a lecture uploaded raw, a press conference. There is nothing to read, and a track reader has no second method to fall back on, because it only ever had one.
- A track exists, but not in your language. Very common outside the big global catalogues. A Korean platform with Korean-only subtitles hands a track reader a Korean track and nothing to pair it with.
- Burned-in subtitles are pixels. A documentary with text printed into the frame has no text track anywhere. Neither does a video whose "captions" were a subtitle file someone forgot to upload.
- DRM is a wall with a specific shape. Netflix encrypts its video inside the browser's protected media pipeline, and its timed text does not arrive as an ordinary
<track>element — it comes through the player's own delivery path and is drawn by the player. Track readers either reach into that player's private internals, which is fragile and breaks without warning, or they do not cover the site at all. - Closed players and cross-origin frames. Captions drawn onto a canvas are images, not text. A player inside a cross-origin iframe, or behind a shadow root, may as well be a photograph.
Road two: listen to the audio
The second road ignores the text entirely. It captures the audio output of the browser tab, transcribes it with a speech recognition model, translates the transcript, and draws the result as a layer on top of the page.
The mechanism matters for what it implies downstream. Audio that reaches your speakers has already been decrypted — it has to be, that is where it is going — so the capture sits below the DRM boundary and the protected pipeline stops being relevant. And because the input is sound rather than text, the limit on coverage is no longer "does a subtitle file exist" but "is there audio playing".
What this road gets right
- Coverage set by sound, not by licensing. Livestreams, webinars, conference talks, university portals, regional video sites, burned-in subtitles, canvas players, video inside iframes, DRM-protected streaming — all of it has audio.
- Two languages even when the platform carries one. The transcript is what was actually said; the translation is added on top. You are not restricted to the tracks somebody chose to license for your region.
- The words, not the edit. A subtitle track is condensed to fit reading speed — clauses shortened, filler dropped, idioms flattened. If you want the exact phrasing, for language learning or to check what a translation left out, transcribing the audio is the only way to get it.
Where it stops
- Latency of a couple of seconds. Speech has to accumulate before there is anything to recognise. Monologue and normal dialogue are fine; rapid exchanges of short interjections are where it shows most.
- Its errors are the errors of hearing. Names, numbers, overlapping speakers, music under dialogue, strong accents, invented terminology. A human subtitle editor never makes these mistakes; a model makes them, fluently and with confidence.
- The tab has to be audible. Mute it and there is nothing to transcribe. This is also the fastest way to test which road a tool is on, which is why it appears again below.
- Tab audio capture is a browser capability, not a phone one. This road is desktop-only, and that is an architectural fact rather than a feature that has not shipped yet.
- It costs compute per minute. Recognition and translation both run on paid infrastructure, second by second, whether or not anyone is watching the result. That is the defining economics of the category, and it explains the shape of the pricing without any figures being involved.
- A transcript, not a subtitle file. What you get is what was said, delivered as lines. It is not the platform's timing and it is not the platform's editorial judgement, and it will never be as polished as a track that a person timed.
Side by side
The same nine questions, asked of both roads:
| Reads the track | Hears the audio | |
|---|---|---|
| Input | Text that already exists | The sound itself |
| Needs a subtitle file | Yes, always | No |
| DRM video | Only via player internals | Yes — audio is decrypted |
| Livestreams | Rarely; nothing to read | Yes |
| Burned-in text | No — pixels | Yes |
| Latency | None | A few seconds |
| Names and jargon | Correct | Occasionally mangled |
| Two languages | Only if both exist | Yes — transcript + translation |
| Breaks first | No track present | Audio unclear |
Read that as a list of trade-offs rather than a scorecard. The two columns are not rival versions of one thing; they are answers to two different questions. One asks "what did the subtitler write". The other asks "what did the person say".
The distinction survives contact with real products
Chrome's built-in Live Caption is road two, implemented inside the browser. That explains a limit which otherwise looks arbitrary: it is bounded by a fixed recognition list of roughly twenty spoken languages, not by websites. It can caption any tab, because it does not care what the tab is — and it cannot handle a language outside its list, whichever target language you pick, because the constraint sits at the input rather than at the output.
Dual-subtitle extensions for streaming services are road one, and that explains the opposite pattern: flawless on a catalogue original with twelve subtitle languages, useless on a regional platform that ships one.
Plenty of newer tools are both at once, switching per site — read the track where it is reachable, transcribe the audio where it is not. When a product claims to work everywhere, that hybrid is usually what is happening underneath, and it is worth asking which half of it you are relying on.
Four tests that identify the road in two minutes
- Try it on something with no subtitles. A webinar recording, a Twitch VOD, a conference livestream. If text appears, it is road two. If nothing appears, it is road one — and it will never work on that class of video, no matter how the settings are configured.
- Mute the tab. Road two goes quiet. Road one keeps rendering, because audio was never its input.
- Check a proper noun. Pick a video with a distinctive name in it. Correctly spelled means a person typed it. Plausibly mangled means a model heard it.
- Pause, then resume. Road two takes a beat to catch up with the new position. Road one is instantly correct, because the timing was already in the file.
There is an indirect fifth test: how the product charges. Metering by the minute implies compute running on a server per user; a flat price implies text that was already sitting there. The pricing shape is a confession about the architecture.
Which road fits your situation
- A big-catalogue original with the tracks you want — road one, every time. Better timing, better spelling, better controls. If a dual-subtitle extension covers the site, use it; that is the case it was built for.
- A regional platform, an indie film, or a title with no track in your language — road two. There is nothing to read, so reading is not an option.
- Anything live — road two. A livestream has no track by definition, and the same is true of a webinar, a call, and a sports stream.
- A course with instructor-uploaded subtitles — road one is fine on the lectures that have them, which is usually the flagship ones. Where the uploads stop, road two is the only thing left.
- Language learning where the exact wording matters — road two. A track tells you what the subtitle editor wrote; you want what the actor said.
What neither road does
- Nothing on a phone, a tablet, or a TV. No tab audio to capture and no page to draw on. Both roads live in a desktop browser.
- Nothing for a file you have already downloaded. That is post-production — a different problem with better tools and higher accuracy ceilings, because it can take as long as it likes.
- Neither hands you a professionally timed subtitle file. Road one reuses one; road two produces speech, and speech is rougher than an edit.
- Neither helps with content that is not licensed where you are. Coverage of audio is not coverage of catalogue.
Bottom line
These are not competing products, they are two different answers to "where does the text come from". If the video already has the subtitle track you want, reading it is faster, cleaner and better spelled, and you should do that. If it does not — because the video is live, because the track was never made, because it exists only in a language that is not yours — then the only remaining source of text is the sound.
The full guide to real-time subtitles walks through every method in order. If you want to try ours, it's called Tablingo — it is a road-two tool, so it captions the audio on any tab, including the ones with nothing to read.