Subtitles and captions

Subtitles and captions are not the same thing

Everyday speech treats them as one thing, and in practice most people build one file. But the HTML standard carries two separate definitions, and those two definitions produce two different outputs.

The WHATWG specification for the kind attribute on the track element says this: subtitles means transcription or translation of the dialogue, suitable for when the sound is available but not understood, for example because the viewer does not understand the language of the audio track. And captions means transcription or translation of the dialogue plus sound effects, relevant musical cues and other relevant audio information, suitable for when sound is unavailable.

So the difference is not language, it is whether the viewer has the sound at all. For a Persian video playing muted in a social feed, what you actually need is captions rather than subtitles, because a viewer who has turned the sound off has to know that a door slammed or the music changed. For the same video put on YouTube for an English audience, you need subtitles.

And a practical consequence most people skip: these are not one file and should not be. Build one file and ask it to do both jobs and the output is cluttered with sound-effect notes for the English viewer and thin for the deaf viewer. Build two, and separate them in the track element itself with kind and srclang. The same specification says srclang must be a valid language tag and that it is required whenever kind is in the subtitles state.

SRT or VTT: which one where

Both are plain text files and both do one job: a time span and a piece of text. Their difference is not one character, but it starts with one.

1
00:00:11,000 --> 00:00:13,000
The first line

WEBVTT

00:00:11.000 --> 00:00:13.000
The first line

The top is SRT and the bottom is VTT. Two differences are visible in those few lines and both are written into the W3C specification: a VTT file must begin with the WEBVTT signature, and the parser aborts if the stream lacks it; and a VTT timestamp puts a full stop before the three digits of thousandths where SRT puts a comma. That one character is why an SRT file renamed to vtt does not work in a browser.

The more important difference is in the table below, and its last row decides.

So the rule is simple: VTT for playback on your own site, SRT for everywhere else. The HTML specification says plainly that if the track URL identifies a WebVTT resource and kind is not in the chapters or metadata state, the file must be a WebVTT file using caption or subtitle cue text. Which means that for a web player, VTT is not a preference; it is what the standard asks for.

Conversely, when you hand the file to a platform uploader or to an editor who will open it in their own software, SRT is the one that opens everywhere. We deliver both on our own video projects and it costs nothing: converting between them is a separator change and one signature line.

Burned or soft? Both are right, for two different places

Burned-in subtitles means the text has become part of the picture pixels and is no longer text. Soft subtitles means the text is a separate file that the player lays over the picture and the viewer can switch off.

Burned has one advantage that cancels every advantage of soft in certain places: it works everywhere. No player can fail to support it, because there is nothing to support. For social platforms that accept no sidecar file, and for a video meant to be passed around, it is the only option.

And it has three costs, all of which show up later. First, it cannot be switched off; if it sits badly, it sits badly forever. Second, it cannot be translated; for an English version you have to export the whole video again. Third, it cannot be read; neither a search engine nor a language model can read text inside pixels, so everything said in that video does not exist for any machine.

That third cost is the one subtitle tutorials almost never mention and the one that matters most to anybody who runs a site. If your video sits on a page that is supposed to rank, a soft subtitle file plus the transcript on the page itself is what makes the content of the video readable. Burning throws that away.

There is also a technical constraint experienced editors learn: never re-export burned-in subtitles at another size. Text burned for a 1080 wide frame and then scaled down to 720 breaks at the edges of the letters and degrades further under compression, because a compressor charges a lot for sharp edges. For each size, burn again from the subtitle file rather than from the previous export. The same principle applies to the whole picture in the lesson on video for the web.

Where automatic transcription breaks

Speech to text models are good today, and the button everybody presses works right up until it does not. Here are four places it breaks, each with a source.

First, the model you choose may not produce a subtitle file at all. The OpenAI reference says the response_format key accepts json, text, srt, verbose_json, vtt and diarized_json, and immediately adds that for gpt-4o-transcribe and gpt-4o-mini-transcribe the only supported format is json. The same company guide says to start with the recommended model and to reach for a specialised model only when you need speaker labels, word timestamps, subtitle formats or translation into English. Which means the model being recommended to you is the one that does not give you a subtitle file. Worth knowing before you spend an hour hunting for an export button.

Second, word timestamps and a subtitle file do not come in one request. The same reference says word level timestamps are only available when response_format is verbose_json, and adds that generating word timestamps incurs additional latency. So you get either an srt file or data you can work with precisely, and if you want both that is two requests.

Third, the file size ceiling. The OpenAI guide says files up to 25 MB, in mp3, mp4, mpeg, mpga, m4a, wav and webm. A half hour video goes past that, so you have to strip and compress the audio and then cut it. And the cut is where the timing slips: every piece starts at zero, and you have to add each piece offset to its timestamps by hand. Somebody who does not know that builds a subtitle file that runs ahead of the picture from the middle onwards.

Fourth, names. This is where Persian takes the heaviest hit and where no number exists. A model that transcribes fluent Persian will still substitute the nearest familiar word for city names, family names and brand names. There is a capability here that almost nobody uses: the ElevenLabs guide for Scribe v2 says the model accepts keyterm prompting of up to 1000 terms, alongside precise word level timestamps, entity detection across 65 entity types and speaker diarization for up to 32 speakers, in more than ninety languages. Which means you can hand the model the list of names in your video in advance. That is one line of work and it has the largest single effect on Persian transcription quality.

And one thing worth stating plainly because many people expect otherwise: the OpenAI translation endpoint translates into English only, not into any language. If you want Persian subtitles from an English video, that is a separate translation job and the subtitle translation lesson is where it belongs.

What a person has to do after the transcript

Automatic transcription gives you text, not subtitles. The distance between those two is four jobs, and no machine does any of them for you.

Check the names and the numbers. This is the one place where a machine error stops being nonsense and becomes meaningful and wrong: a wrong name in a subtitle is worse than a broken sentence, because the reader does not notice it and believes it.

Break the lines, and break them on a grammatical boundary. A cue that splits in the middle of a phrase makes the reader read it twice. The right boundary is where you would pause if you were saying it.

Time the cues against the speech rather than against the text. A cue should appear slightly before the sentence starts and stay slightly past its end. If you are working from a cut audio file, this is where the offset of each piece has to have been added.

And look at Latin text inside a right to left sentence. Display direction is not identical across players, and a Latin name or a number at the end of a right to left line lands in the wrong place in some of them. The practical fix is to view the file in the player it will actually be used in, not in a text editor. This is the one part of this lesson that reading cannot solve.

One simple rule we hold to on our own projects: add nothing to the text that is not in the audio. If the model has improved a sentence, that sentence is no longer what the speaker said, and a subtitle that is not what the speaker said is a far worse error than a spelling mistake.