How do I add live captions to my webinars or calls?

This page may contain affiliate links from which Blur Studio earns commissions.

Some of your audience will always need captions to actually follow a webinar or call, whether that's a hearing need, a noisy environment on their end, or simply someone who processes written words better than spoken ones in real time. Treating captions as optional loses exactly those people, quietly, with no feedback telling you it happened. Recordings you publish later need subtitle files, which making subtitles and SRT files covers.

Start with what your platform already has

Zoom and Google Meet both include some form of built-in live captioning, and for a standard webinar or call, that's genuinely the first thing to try, since it needs no extra setup or cost beyond whatever plan you're already on. Check what's included on your specific plan rather than assuming; caption features and limits vary by tier and change over time, so confirm directly on your platform's current plan page before you count on it for an important event.

Why captions matter beyond accessibility

Captions solve more than one problem at once, which is worth knowing when you're deciding how much effort to put into getting them right. Beyond the accessibility need, a meaningful share of any audience watches with sound off or low, in an open office, on public transit, or simply because they focus better reading along. For a public-facing webinar, captions also become a compliance consideration in several jurisdictions once you're a business serving customers, not just a nice-to-have. And a transcript generated alongside live captions becomes a useful asset after the event ends too: a searchable record of what was said, source material for a written recap or blog post, and a way to confirm exactly what was promised or claimed during the session if that's ever disputed later. Treating captioning as a one-time accessibility checkbox misses most of this value.

When the built-in option isn't enough

Built-in captions fall short when you're running the event on a platform that doesn't offer them at all, need accuracy on specific technical vocabulary, or want captions in a language your platform doesn't support well. That's where a dedicated speech-to-text API comes in. ElevenLabs' Scribe v2 Realtime streams live transcription with roughly 150 milliseconds of latency, which is fast enough that captions feel essentially simultaneous with speech rather than visibly lagging behind. It costs $0.39 an hour through the API and supports up to 50 custom keyterms (think product names or speaker names) to improve accuracy on your specific vocabulary, at an additional cost on top of the base rate. Specialist vocabulary has its own fixes, described in technical terms and part names wrong in transcripts.

The honest limitation here is that this is a developer-facing API, not a captioning app. Getting live captions from it into your actual webinar or call needs either a developer wiring it into your event setup, or a third-party tool that's already built that connection on top of the API for you. If neither of those is available to you, the built-in platform option above is the realistic path. The batch side of the same product is reviewed in ElevenLabs Speech to Text (Scribe).

Language support is where this gap shows up most often in practice. A platform's built-in captions usually cover a handful of major languages well and others poorly or not at all, which is a real problem if your audience spans multiple regions and you're running one session rather than separate language-specific ones. A dedicated transcription API like ElevenLabs' Realtime API with broad language coverage can serve an audience your webinar platform's own captions simply don't support, which is often the actual reason a team moves off the built-in option rather than general accuracy complaints.

What the latency budget actually means for a live event

150 milliseconds sounds abstract until you put it next to how people actually read. A caption that lags noticeably behind speech is distracting and genuinely harder to follow than no captions at all, since the viewer's eyes and ears are telling them two different things at once. At roughly 150ms, the delay is well under what a viewer consciously notices, so captions read as essentially synchronized with the speaker rather than as a lagging transcript scrolling underneath. This matters more for a fast-paced panel discussion or Q&A with multiple speakers than for a single presenter reading from slides at a measured pace, since overlapping speech and quick exchanges are where latency becomes visible first.

Display matters alongside latency. Most caption systems show one or two lines at a time and need to decide how much text to show before clearing it; too much on screen at once and viewers can't keep up reading, too little and context gets lost mid-sentence. If you're building directly on the API rather than using an established captioning tool, this line-length and clearing logic is something you'll need to design, not something the transcription API hands you automatically.

One thing worth knowing before you build on the API

A developer reported, in a recent discussion, unexpectedly high usage billing relative to the actual recorded time while using ElevenLabs' official React SDK with Realtime Scribe, with the usage dashboard not reflecting the API calls being made and a slow response from support over several days. That's one reported case, not evidence of a widespread problem, but if you're building directly on the SDK rather than through an established third-party tool, it's worth monitoring your own usage dashboard closely in the first weeks and flagging any mismatch early rather than assuming it will resolve itself.

What I'd actually tell someone planning a webinar

If you're running one-off or occasional webinars, use your platform's built-in captions and don't overthink it; the accuracy difference for a general-audience talk rarely justifies building custom infrastructure. If you're running events regularly, in a specific technical field with vocabulary your platform's captions get wrong often, or need languages your platform doesn't support well, that's when the extra setup for a dedicated API starts to pay for itself. Most people land in the first category and don't need to move past it. If you're not sure which category you're in, run one event with built-in captions on and ask a handful of attendees afterward whether the captions were accurate and easy to follow; that real feedback tells you more than guessing from the plan description alone.

What this actually costs for a regular webinar series

If you run a weekly hour-long webinar, that's roughly $1.56 a month in raw transcription cost through the API at the $0.39 hourly rate, trivial next to almost any other cost of running the event. The real cost isn't the per-hour rate, it's the engineering time to wire it in and keep it running reliably: handling reconnects if someone's stream drops mid-event, routing the caption stream to wherever viewers actually see it, and testing across whatever devices and browsers your audience uses. For a single event or an occasional series, that setup cost rarely makes sense against the built-in option. For a business running webinars as a core part of how it sells or trains, where captioning quality and language coverage genuinely affect outcomes, the setup cost is a one-time investment against a cost per event that stays close to nothing. For a written record of every session afterward, see transcribing every call automatically.

Step by step

1. Check your webinar or meeting platform's current plan for what live captioning is actually included and in which languages.
2. Run a real test with captions on before the actual event, not just a feature check in settings.
3. If built-in captions aren't accurate enough or aren't available on your platform, look at whether a tool you already use connects to a realtime transcription API, before building a custom integration from scratch.
4. If you do build on the API directly, add your known vocabulary (product names, speaker names) as keyterms, and watch the usage dashboard closely during your first real event.

How I'd approach this

This is exactly the kind of thing worth a custom build once captioning becomes a recurring, business-critical part of how you run events: wiring realtime transcription directly into your own event platform, with the vocabulary and languages your specific audience actually needs, rather than working around whatever a generic webinar tool happens to support. For an occasional webinar, I'd point you at your platform's own captions first and save the custom build for when you're actually running into its limits repeatedly. The build itself, when it's warranted, usually isn't large: a streaming connection to the transcription API, a reconnect handler for when someone's network drops, and a caption display tuned to your actual audience's reading speed and the pace of your typical event. Once that exists, it keeps working the same way for every future webinar, so the setup cost is paid once, not per event.