There are exactly two architectures for captioning an online meeting, and the choice between them decides everything else, who has to approve it, what the participant list looks like, and how many languages the audience can read.
Architecture one: join the call
A transcription bot joins the meeting as a participant. It appears in the list, it needs whatever permissions the platform requires of an application, and in an organisation of any size it needs your IT department to authorise it first.
That last part is the one that bites in practice. Getting a tool approved inside a corporate tenant is a process, and the process routinely takes longer than the event you were trying to caption.
Architecture two: listen to the computer
The alternative starts from an observation: at an online event, the voices are already inside the organiser’s computer. They are coming out of the speakers. A desktop application running on that same machine can capture that audio directly.
Nothing joins the call. There is no application installed inside the platform, nothing in the participant list, and no integration for anybody to authorise or revoke.
It also means there is no per-platform code path. The capture cannot tell which application produced the sound, so Zoom, Teams, Meet, Webex and whatever replaces them next year are all the same case. That is not a roadmap promise; it is a consequence of where the audio is being taken from.
What this buys the audience
The part that matters to attendees is not the architecture, it is the choice.
In Zoom, which we tested, each viewer’s caption bar shows one language at a time. Letting each viewer pick a translated one takes a paid add-on or a higher plan on the host’s account (Zoom calls it Translated Captions), and covers the languages on Zoom’s list that the host has switched on. Microsoft documents the same for Teams with a Teams Premium licence; Teams we have not tested. Either way, the captions stay inside the call: the people in the room see none of them.
A link in the meeting chat does not depend on any of that. Each person opens it in a browser and picks their own language: up to twelve reading languages at once in a single event, from a catalogue of 58, changeable mid-meeting. No app, no account, no sign-up. If they would rather listen than read, the browser reads it aloud through their own earphones, where the device has a voice for that language.
Three practical notes
You keep hearing the meeting. This is worth stating because it is the first thing people ask. The capture does not mute anything; the operator goes on hearing the meeting they are captioning.
On a Mac there is one permission prompt. macOS asks once for screen recording, the app restarts, and after that it behaves exactly as it does on Windows.
Hybrid is the same session. If half the audience is in a room, the same event goes out to the venue screen over NDI or HDMI. The people on the call and the people in the room, one session, one code, one invoice.
And if you specifically want the native caption bar
Zoom exposes a manual-captioner token: the host enables the caption API token in their settings, copies it, and a third-party tool can push finished lines into Zoom’s own caption bar. There is no Marketplace review and nothing to install. Worth knowing: that token is offered on free Zoom accounts too, which we checked on 2026-09-12, contrary to what Zoom’s own help pages say.
We have built that path and run it against a real Zoom meeting, so it works. The main route (a link in the chat and a browser) does not depend on it, and it is still the one we would point you at first, because it gives the audience twelve languages instead of one.