SRT, VTT and the formats in between
SubRip (.srt) is the simplest and most widely supported subtitle format: numbered cues, a timestamp line with start and end times, and the text. Its timestamps use a comma as the decimal separator, which is the detail most often got wrong when generating files by hand.
WebVTT (.vtt) is the format browsers use with the HTML <track> element. It requires a WEBVTT header line, uses a full stop rather than a comma in timestamps, and supports positioning, styling and cue identifiers that SRT does not. Converting SRT to VTT is largely a matter of the header and the separator.
Advanced SubStation Alpha (.ass) supports full styling, positioning and animation, and is standard in fan-subtitling and anime. Broadcast uses different systems again — TTML and EBU-STL — with their own timing conventions. Support varies: SRT is accepted almost everywhere, VTT is required for browsers, and styled formats are frequently stripped down on upload.
Timing and reading speed
Subtitles are constrained by reading speed rather than by speech. The widely used guidance is a maximum of about 17 characters per second for adult content and considerably less for children's programming, with a minimum cue duration of roughly one second and a maximum of six. A cue shorter than a second registers as a flash rather than as text.
Line length should stay around 42 characters, with a maximum of two lines. Longer lines force the eye across the screen and away from the picture; three lines obscure too much of the frame. Where a sentence must be split, break at a natural syntactic boundary — after a clause rather than between an article and its noun — since a badly placed break measurably slows reading.
Cues should be synchronised to speech onset, with a small lead of a few frames being acceptable and a lag being far more noticeable. Subtitles should also respect shot changes: a cue spanning a cut is disorienting, and the convention is to end the cue on the cut or to start it after.
Subtitles, captions and who they are for
The distinction matters both legally and practically. Subtitles assume the viewer can hear and render dialogue only, typically for translation. Captions assume the viewer cannot hear and must convey everything relevant on the audio track — speaker identification, sound effects, music cues, tone of voice.
That difference is what makes captions an accessibility requirement rather than a convenience. WCAG requires captions for prerecorded audio content at level A, and jurisdictions including the United States under the ADA and the EU under the Accessibility Act impose obligations on various categories of publisher. Automatic captions alone generally fall short, because their error rate on names, technical terms and overlapping speech is high enough to change meaning.
There is also a large audience beyond deaf and hard-of-hearing viewers. Surveys consistently find that a majority of viewers use captions at least some of the time — in noisy environments, in quiet ones where sound would disturb others, or simply for comprehension. Captions also make video content searchable and indexable, which is the reason many publishers add them even where no obligation applies.