Complete Guide to Video Subtitles: SRT vs. WebVTT Formats

Why Video Subtitles Are Essential

Subtitles and closed captions are no longer optional. According to industry studies, over 80% of social media videos on mobile devices are watched on mute. Without captions, viewers scroll past within the first three seconds.

Furthermore, subtitles provide critical accessibility for individuals who are deaf or hard of hearing, improve comprehension for non-native language speakers, and provide rich semantic text that search engine crawlers can index.

SubRip (.srt) Architecture & Syntax

Originating from the Windows DVD-ripping era, the SubRip (.srt) format is the most widely supported subtitle format on earth. It is a plain text file consisting of sequentially numbered cue blocks separated by blank lines.

Each cue contains four elements: a numeric counter, start and end timestamps formatted as `hours:minutes:seconds,milliseconds` (note the comma separator), the subtitle text itself, and an empty line.

WebVTT (.vtt) Standard & Modern Features

WebVTT (Web Video Text Tracks) was created by the W3C specifically for HTML5 `<track>` elements in web browsers. While inspired by SRT, WebVTT introduces several modern capabilities.

First, WebVTT files must begin with the header `WEBVTT`. Second, millisecond timestamps are separated by a period (`.`) rather than a comma. Third, WebVTT supports CSS styling, voice tags (`<v SpeakerName>`), text positioning (`line:80% align:start`), and ruby annotations for East Asian typography.

Direct Syntax & Feature Comparison

Compare the capabilities of SRT and WebVTT side-by-side:

Reading Speed, Line Length and Cue Duration

Correct timecodes are necessary but not sufficient. A subtitle track can be perfectly synchronised and still unusable, because the constraint that actually matters is whether a viewer can read each cue in the time it is on screen while also watching the picture.

The broadcast convention is to cap reading speed at roughly 17 characters per second for adult content, dropping to around 13 for children's programming. Line length is held near 42 characters, and no cue runs more than two lines, because a third line starts covering the image and forces the eye too far from the action. The minimum duration matters as much as the maximum: a cue shorter than about one second registers as a flash rather than text, even when the words themselves are brief. Seven seconds is the usual ceiling, after which a static caption begins to feel abandoned.

Automatically generated cues routinely violate all of this, because a speech model segments on pauses rather than on readability. The characteristic failure is a long sentence delivered quickly, emitted as one cue of 140 characters sitting on screen for two seconds. The fix is to split it across consecutive cues at a natural grammatical break — after a clause, not mid-phrase — which is the single highest-value edit you can make to a raw transcript.

Captions vs. Subtitles: Not the Same Thing

The two words are used interchangeably in casual conversation, and the distinction matters as soon as accessibility is the goal rather than convenience.

Subtitles assume the viewer can hear and transcribe dialogue only. They exist to bridge a language gap, which is why a foreign-language film shows subtitles rather than captions. Captions assume the viewer cannot hear and therefore carry everything in the soundtrack that conveys meaning: speaker identification when it is not obvious who is talking, relevant non-speech sound such as [door slams] or [phone ringing], and music cues when the music is doing narrative work. This fuller form is often labelled SDH, for Subtitles for the Deaf and Hard of Hearing.

The practical consequence is that an AI transcript gives you subtitles, not captions. It will faithfully render spoken words and silently omit the knock at the door that the dialogue responds to. Turning one into the other requires a human pass to add sound events and speaker labels. If you are producing captions to meet an accessibility obligation, that editing pass is the work — the transcript is only the starting point, and treating automated output as finished captions does not discharge the obligation.

Character Encoding and Non-Latin Scripts

Subtitle files are plain text, which makes them simple to edit and also makes them vulnerable to the oldest problem in text processing. A file is just bytes; interpreting those bytes as characters requires knowing the encoding, and nothing inside a .srt file states which one was used.

When a player guesses wrong, the result is mojibake — accented characters, Cyrillic, Greek, Arabic and CJK text rendering as strings of nonsense symbols. The modern answer is to save everything as UTF-8, which covers every script in one encoding and is what WebVTT mandates outright. Legacy SRT files frequently arrive in regional single-byte encodings such as Windows-1251 for Cyrillic or Windows-1256 for Arabic, and converting them to UTF-8 is usually all that is needed to fix garbled output.

A byte order mark adds a further wrinkle. Some Windows editors prepend an invisible marker to UTF-8 files, and while most players tolerate it, a few will treat it as part of the first subtitle number and fail to parse the file at all. If a subtitle track works everywhere except one specific player, a stray BOM is a strong suspect. Right-to-left scripts bring their own considerations, since the display order depends on the player's bidirectional text handling rather than anything in the file.

Burned-In Captions vs. Sidecar Files

There are two ways to get text onto a video, and they are not substitutes for one another — the choice determines what the viewer can control and whether the text is useful to anything other than a human eye.

A sidecar file keeps the subtitles as a separate .srt or .vtt alongside the video. The viewer can switch it off, change language, restyle it, or have a screen reader consume it. Search engines and platforms can read it, which means the dialogue becomes indexable text rather than pixels. It is also trivially editable after the fact: fixing a typo means changing one line, not re-encoding anything.

Burned-in captions are rendered permanently into the picture during encoding. Nothing can turn them off, restyle them, or extract the text. The reason to do it anyway is that a great many playback contexts ignore sidecar files entirely — most notably social feeds that autoplay muted, where burned-in text is the only kind that reliably appears. The cost is a full re-encode, so it should be the last step in a pipeline, performed on a master you have kept, never on your only copy.

• Sidecar: switchable, multilingual, indexable, editable. The default choice.
• Burned-in: survives any player, required for muted social autoplay, permanent.
• Keep the sidecar file even when you burn in. You will want it again.

How to Fix Subtitle Timing & Audio Drift

A frequent problem when working with subtitles is timing desynchronization. Subtitle sync issues fall into two categories:

1. Constant Offset: Every subtitle appears exactly 1.5 seconds too early or too late. This is solved by applying a uniform timecode shift across all cues.

2. Progressive Drift: Subtitles start in sync, but gradually fall behind by several seconds over an hour. This occurs when the video's frame rate (e.g. 23.976 fps) does not match the timecode base of the subtitle file (e.g. 25 fps).

MediaDocks' built-in Subtitle Studio allows you to nudge individual start/end times or shift every cue across the entire track by half a second with a single click.