Captions arrive in three quite different forms, and the choice between them is usually made by accident at the point of export. It is worth making on purpose, because one of the three is permanent.
The three forms
Sidecar file. A separate .srt or .vtt alongside the video. The player loads it and draws the text. It can be switched off, replaced, corrected, translated and read by search engines. This is the form that keeps every option open, and the one that does the accessibility work properly rather than decoratively. Being a plain text file, it is also subject to the usual encoding traps: an SRT saved as Windows-1252 and read as UTF-8 turns every accented character into noise.
Embedded track. The subtitles live inside the container as their own stream, the way audio does. One file to move around, still switchable off in players that support it. MKV handles this well, MP4 support is patchier, and browsers mostly ignore embedded subtitle tracks entirely.
Burned in (hardsub). The text is drawn into the pixels during encoding. It always appears, on every player, in every context, at the size and position you chose. It cannot be turned off, cannot be corrected, cannot be translated and cannot be selected as text, and you cannot get the clean video back without re-encoding from the original.
What an SRT actually looks like
There is nothing clever in the format, which is why it is easy to fix by hand:
1
00:00:02,400 --> 00:00:05,120
The deploy finished at four in the morning.
2
00:00:05,300 --> 00:00:08,000
Nobody noticed until the reports ran.
A cue number, a time range with a comma before the milliseconds, the text, a blank line. WebVTT is nearly the same with a WEBVTT header and a full stop instead of the comma before the milliseconds.
That similarity is also the usual bug: an SRT with full stops in the timestamps, or a VTT with commas, will be rejected or silently ignored by strict players.
When burning in is the right call
Burned-in captions exist for one legitimate reason: platforms that autoplay muted and either do not support subtitle files or do not show them by default. On a feed where the majority of viewers never hear the audio, text that always appears is the whole point.
Outside of that, burning in costs you things worth keeping:
- A typo means re-exporting from the original.
- Translation means a separate encode per language.
- Nothing can index the text, so the spoken content is invisible to search.
- Viewers who need larger text cannot change it.
- The captions cover the picture permanently, including on a phone where they may overlap the interface.
If both are needed (burned in for the feed, sidecar for the site) export the clean master first and produce the burned version from it. Never the other way round.
Auto-generated captions and the edit pass
Speech recognition has become good enough that starting from an automatic transcript is almost always faster than typing one. It is not good enough to publish unedited, and the errors cluster predictably:
- Proper nouns. Names of people, products and companies come out phonetically.
- Numbers. "Fifteen" and "fifty" are the classic pair, and version numbers, prices and dates are where a caption error becomes a factual error.
- Punctuation. Modern models insert it, but sentence boundaries in unscripted speech are ambiguous.
- Overlapping speakers. Two people talking at once tends to produce one confident and wrong sentence.
- Technical terms and acronyms. Anything domain-specific will need a pass.
Running speech-to-text to get a timed draft and then correcting those five categories is perhaps ten minutes per recorded hour, against an hour or more of transcribing from scratch.
Writing captions people can read
- Two lines maximum on screen, roughly 32–42 characters per line.
- A cue should stay up long enough to read: about one second per three words, with a 1.2 s minimum.
- Break lines at natural phrase boundaries, not mid-noun-phrase.
- Identify speakers when it is not obvious who is talking.
- Include meaningful non-speech sound (a door, a laugh, music starting) where it carries information.
These are accessibility requirements as much as style preferences: captions exist first for viewers who cannot hear the audio, and a caption that flashes past unreadably fails that job while technically existing.
The order that keeps options open
- Export the clean video master.
- Generate a draft transcript from the audio.
- Correct names, numbers and punctuation; fix line lengths and timing.
- Ship the SRT as a sidecar wherever it is supported.
- Produce a burned-in version, from the master, only for platforms that need it.
Transcription is the step worth thinking hardest about, because the output is a searchable text copy of everything that was said. If the recording is an internal meeting, a local transcription model is worth the extra setup: the alternative leaves a full transcript of that meeting sitting on someone else's server.
The sidecar is the part that most often needs converting. HTML5 players and YouTube expect WebVTT, while video editors and desktop players expect SRT, and the two differ mainly in the header and the decimal separator in each timestamp. SRT to VTT and VTT to SRT convert between them in the browser, so the transcript stays on your machine.