The Delivery Toolkit We Rely On: SRT, VTT and Embedded Captions
Marcus Delaney
6 minutes to read
A look at the file formats and export habits we use when captions leave the editing desk, and how to pick between sidecar files and captions built into the video.
Why delivery is the last real decision
Most people treat export as a button at the end of the job. In my experience it is the step where careful work either survives or quietly falls apart. A caption file can be accurate, well timed and neatly labelled, and still arrive in a format the video platform ignores, or with line breaks that were rearranged on import.
This is the fourth note I have written on file formats and delivery, and it deals with the tools and habits we lean on rather than the theory. In the course, learners reach this module after transcription, timing and review, so the text is already settled. What remains is deciding what shape it should take so that it reaches the viewer intact.
Early autumn is a busy stretch for event and talk recordings, which makes it a good moment to tidy your delivery routine before the next batch arrives. A few settled habits save a surprising amount of rework later in the season.
SRT: the plain, widely accepted choice
SRT is the format we teach first, because it is simple enough to read in any text editor. Each caption is a numbered block with a start and end time and one or two lines of text. There is no styling to go wrong, which is exactly why so many players and editing programs accept it without complaint.
We rely on SRT when a client says only that they need a caption file and the destination is unknown. It travels well between tools, and a learner can open it, spot a timing slip by eye and fix it in a minute. The trade-off is that it carries almost nothing about appearance.
If you need italics for an off-screen voice or a bit of emphasis, some players will honour basic tags and others will print them as literal characters. We test on the intended player before promising any styling in SRT, and we say so plainly when a request goes beyond what the format can hold.
- Best for broad compatibility
- Easy to inspect and correct by hand
- Limited styling and positioning
VTT: when the web is the destination
VTT looks similar to SRT on the surface but was built with web video in mind. It allows position settings, simple styling and notes, and browsers read it directly. When a recorded talk will sit on a web page, VTT is usually the better fit.
Priya Raman, who teaches the formats module with me in the picture, likes to have learners open the same captions in both formats side by side. The difference becomes obvious: VTT begins with a header line, uses a full stop rather than a comma in the timestamps, and can place a caption higher on the screen when lower text would cover a slide.
That positioning is a real advantage for conference recordings where the speaker's name or slide title appears near the bottom. We do not move captions around for decoration, only to keep them clear of on-screen text. Moving them without a reason makes the viewing less steady, not more readable.
Embedding captions inside the video
Embedded captions are part of the picture itself, sometimes called open or burned-in captions. They cannot be switched off, and they cannot be lost when a file is uploaded somewhere that strips sidecar files. For a clip shared on a social feed or played on a screen in a lobby, that certainty has real value.
The cost is flexibility. Once captions are in the image, fixing a typo means exporting the video again, and viewers cannot change size or language. Because of this we always keep the separate SRT or VTT file as the master, and treat the embedded version as a copy made from it.
We also check that the text sits inside the safe area of the frame and stays readable against changing backgrounds. A clean sans serif at a comfortable size, with a plain backing or outline, does more for readability than any clever design choice.
- Cannot be turned off by the viewer
- Needs a fresh export for every correction
- Always keep the sidecar file as the master
The checks we run before sending anything
Before a file leaves us, we run through a short routine. We open it in a plain text editor to confirm the encoding is correct and special characters such as accented letters and curly quotes display properly. Broken characters are one of the most common faults and one of the easiest to catch.
Next we load the captions against the video in at least one player that matches where the client will publish. We watch the opening, a busy middle stretch and the ending, because timing drift tends to show at the extremes. Any caption that flashes by too fast or lingers past the next speaker gets adjusted.
Finally we name files so they sort sensibly, with the video title and the format in the filename. It sounds small, yet a client holding six versions of a talk will thank you for labels that say which one is current. Learners practise this naming habit from their first export.
- Check encoding and special characters
- Test in the player the client will use
- Name files clearly by title and format
Choosing without overthinking it
If you are unsure, start with an SRT file and keep it safe. It will work in most places and can be converted to VTT later with little effort. Choose VTT when you control a web page and want the extra positioning. Choose embedded captions when the platform gives you no way to attach a file.
Many projects end up using more than one. A talk might go on a website with VTT, circulate as a short clip with embedded captions, and sit in an archive with the SRT master. That is ordinary, and it works as long as every copy comes from the same corrected text.
What matters is that the choice follows where the viewer will watch, not what is easiest for the person exporting. We teach learners to ask that question first, and the right format usually becomes clear within a minute.