Subtitles and Captions: A Practical Guide to SRT and VTT Files

A caption file is the only part of a video that some viewers will ever read. People watch on trains, in open-plan offices and late at night with the sound off. Millions more are deaf or hard of hearing. For a large slice of any audience, the text is the video. The file carrying that text is almost always one of two formats.

SubRip Subtitle files, known by the extension .srt, came out of a DVD-ripping tool in the early 2000s. They are now the nearest thing subtitling has to a universal currency. Web Video Text Tracks, or WebVTT, is the World Wide Web Consortium standard built for HTML5 video. Both are plain text. Both can be written in any editor. Both fail in odd ways if one comma sits where a full stop belongs.

Subtitles, captions and SDH are not the same thing

The three words describe three different jobs, and platforms treat them as separate deliverables.

• Subtitles assume the viewer can hear the audio. They translate dialogue into another language or render it as text for clarity.
• Captions are written for viewers who cannot hear the audio. They carry speaker labels, meaningful sound effects and notes about music.
• SDH means subtitles for the deaf and hard of hearing. It is a hybrid used on Blu-ray and streaming services, adding caption detail to a subtitle track.

A second split matters for delivery. Closed captions are a separate file the viewer switches on and off. Open captions are burned into the picture and cannot be turned off. British usage folds most of this into the single word "subtitles", while American usage keeps captions distinct. Platform documentation mixes both freely, so read the requirements rather than the label.

The stakes are not only editorial. In the United States, the Federal Communications Commission requires closed captioning for broadcast television and for much online video that aired there first. The Web Content Accessibility Guidelines make captions a baseline for prerecorded video with sound. These small text files are where accessibility law meets everyday production work.

Inside an SRT file

SRT has no official specification and a remarkable survival record. It takes its name from SubRip, a Windows program that pulled subtitles off DVDs. The saved file was so simple that everyone copied it. An SRT file is a list of cues, and every cue has four parts.

The four parts of a cue

1
00:00:12,540 --> 00:00:15,190
The first thing to understand
about a movement is torque.

2
00:00:15,190 --> 00:00:18,020
Everything begins
with the mainspring.

Read it from the top. A sequential number opens the cue. The timing line follows, with a start time, an arrow made of two hyphens and a right angle bracket, and an end time. One or two lines of text come next. A blank line closes the cue. That blank line is structural, not decorative; without it the player cannot tell where the cue ends.

Timecodes run hours, minutes, seconds and milliseconds. Colons separate the first three. A comma separates the milliseconds, a legacy of the format's European origins, where the comma is the decimal mark. Write 00:00:12.540 with a full stop and some players shrug while others reject the whole file.

Where SRT files break

• Wrong encoding. Save as UTF-8 without a byte order mark. Accented letters and curly quotes turn to gibberish under legacy encodings such as Windows-1252.
• Overlapping timecodes. A cue that starts before the previous one ends behaves differently in every player. Keep the sequence strictly ordered.
• Missing blank lines. One deleted empty line can silently swallow every cue after it.
• Frame-rate drift. A file timed against 23.976 fps footage will slide out of sync on a 25 fps version of the same video. The gap grows as the runtime does.
• Formatting assumptions. Many players honour simple <i> and <b> tags. Plenty ignore them. Nothing important should depend on italics.

Inside a WebVTT file

WebVTT began as SRT adapted for browsers and grew into a formal standard, published by the W3C as the Web Video Text Tracks format. A VTT file looks like an SRT file that has been to finishing school.

WEBVTT

NOTE Workshop interview, part one

intro-01
00:00:12.540 --> 00:00:15.190 line:85% align:center
<v Interviewer>The first thing to understand
about a movement is torque.

Header, identifiers and NOTE blocks

The file must open with the line WEBVTT. Milliseconds take a full stop rather than a comma. Cue numbers become optional identifiers, and they may be names such as intro-01, which makes cues addressable from scripts and CSS. NOTE blocks hold comments the viewer never sees, so a captioner can leave a query for the reviewer inside the file itself.

Cue settings, voice tags and ::cue styling

The extras after the timing line are the real reason to choose VTT. The line, position, size and align settings move a caption out of the way of on-screen text such as a lower third. Voice tags like <v Interviewer> mark who is speaking and can be styled separately.

Presentation is kept apart from the words themselves. A STYLE block, or CSS on the hosting page, restyles every caption through the ::cue selector: typeface, size, colour, background. That separation is the discipline described in design minimalism from watch dials to interfaces, where legibility beats decoration.

The decisive advantage is native support. Every modern browser loads a VTT file through the HTML5 <track> element and paints it over the video with no plugin and no player-specific trick.

SRT vs VTT: the differences that matter

For plain dialogue the two are nearly interchangeable, and converting takes minutes. The differences show at the edges.

The practical rule is short. Publishing to your own site or a web player? Use VTT. Delivering to platforms, clients or offline players? SRT is the safest common denominator, and most large platforms accept either. Keep one master file in VTT and export SRT on demand. Downgrading loses only presentation, while upgrading cannot restore information that was never recorded.

Writing captions people can actually read

A valid file can still make for a miserable watch. The craft of captioning is mostly the craft of respecting how fast people read.

Timing and reading speed

The BBC subtitle guidelines are among the most thorough public style guides in the field. They work to a reading speed of roughly 160 to 180 words per minute. In practice a full two-line caption needs three to four seconds on screen. Cues under about one second flash past unread. Cues that linger past six or seven seconds make viewers read them twice. Captions should appear as the words are spoken, never half a sentence behind.

Line length and where to break

Two lines is the ceiling and 37 to 42 characters per line is the comfortable range. Where you break the line matters as much as where you end the cue. Keep grammatical units together, so an article stays with its noun and a preposition stays with its phrase. One bad break makes a reader stumble. A file full of them makes the viewer give up.

A caption has done its job when nobody remembers reading it.

Sound, speakers and music

Captions carry the soundtrack, not just the script. Name the speaker whenever it is not obvious who is talking. Mark sounds that carry meaning, such as [phone buzzes] or [door slams]. Note the presence and mood of music, and give song lyrics when they matter to the story. Resist paraphrase. Edit only when reading speed genuinely demands it, and keep the speaker's own words wherever you can.

From transcript to timed captions

Captioning is transcription with a clock attached. Reliable workflows treat those as two separate problems and solve them in order. The five steps below slot into the wider transcription workflow we map across this journal.

1. Start from an accurate transcript. Every timing decision inherits the quality of the text, so begin the way you would when transcribing an interview: clean audio in, careful text out.
2. Let software align the words. Speech recognition produces word-level timestamps as a by-product of how a speech model times every word it writes. That turns hours of manual cue-setting into a review task. Services such as TRANSCRIPT.YOU export both SRT and VTT from the same pass.
3. Segment for the eye, not the ear. Automatic segmentation follows pauses in the audio. Good captions follow grammar. Expect to merge and split cues by hand.
4. Review against the audio. Give proper nouns, figures and technical terms the closest attention. The errors counted equally by word error rate are not equal to your viewers.
5. Validate before publishing. Load the file in the player you actually ship with and watch a few minutes at normal speed. A caption file is only correct in context, which is the same argument made in how precision engineering tests to a tolerance.

Fixing the faults that show up most

• Captions do not appear at all. Check the file extension, the MIME type and the WEBVTT header. Any of the three will stop a browser track loading.
• Strange characters instead of accents. The file was saved in a legacy encoding. Re-save as UTF-8 and reload.
• Everything drifts late. Frame-rate mismatch or a trimmed opening. Apply a single offset to all cues rather than fixing them one at a time.
• Text sits on top of the graphics. Move the cue with a VTT line setting instead of rewording it.
• Two speakers merge into one caption. Split the cue and mark the change of speaker with a dash or a voice tag.

The text is part of the video now

Caption formats are unusually stable for web technology. SRT has barely changed in twenty years. WebVTT is settled, with growth happening around it rather than inside it.

What has changed is the cost of the work. Automatic transcription and alignment have collapsed the hours involved, leaving human judgement where it belongs: in phrasing, segmentation and review. That balance is the subject of our comparison of where human judgement still beats a machine draft. It shapes any team publishing video at volume, much as it shapes everyday meeting transcription practice.

Captions repay the effort several times over. They open your work to viewers who cannot hear it. They keep it watchable in silence. They make every spoken word searchable and hand you a ready base for translation. The sound of your video is optional to more of your audience than you think. The text increasingly is not. More guides on turning speech into usable text sit in the Voice & Transcription hub.