The client’s web team asks for a VTT, whoever runs their YouTube channel wants an SRT, and LinkedIn takes only one of the two. The subtitles inside are the same in every case.
Both formats are plain text with a list of subtitles, each with an in time, an out time and one or two lines of text. The differences take a couple of minutes to fix by hand, and any one of them is enough for a platform to reject the file.
In short
- SRT and VTT hold the same subtitles: VTT starts with WEBVTT and puts a dot, not a comma, before the milliseconds.
- VTT can position and style a subtitle, and basic SRT can’t.
- Send VTT to your own website, SRT to LinkedIn and Meta ads, and whatever a streaming or broadcast spec names.
- Save every subtitle file as UTF-8, or accented names break.
- Export subtitles from the version you’re delivering, and check converted files before you upload them.
The same subtitles in both formats
Here are two subtitles as an SRT file:
1
00:00:01,000 --> 00:00:03,800
Three days, two thousand people
and one plan for the year ahead.
2
00:00:04,200 --> 00:00:06,000
Welcome to the summit.
Each subtitle gets a number, starting at 1. The timing line gives hours, minutes and seconds, then the milliseconds after a comma. The text comes next, and a blank line closes the subtitle.
The format comes from SubRip, a free program from around 2000 that pulled subtitles out of video files, and it never got a formal specification.
The same two subtitles as VTT:
WEBVTT
00:00:01.000 --> 00:00:03.800
Three days, two thousand people
and one plan for the year ahead.
00:00:04.200 --> 00:00:06.000
Welcome to the summit.
The file has to start with the word WEBVTT, and the milliseconds come after a dot. Numbers are optional (VTT calls them cue identifiers), and so are hours, so 00:04.200 is a valid time.
The full name is WebVTT, a W3C format made for video on web pages.
What VTT can do that SRT can’t
A VTT subtitle can say where it sits on screen. These instructions are called cue settings, and they go right after the timing:
00:12.000 --> 00:14.500 line:0
line:0 moves that subtitle to the top line of the picture, which is what you want for the few seconds when a lower third or a product shot fills the bottom of the frame. Other settings control horizontal position, width and alignment.
VTT also has tags for bold, italic and underline, a tag that marks who is speaking, and a STYLE block that takes CSS, though players vary in how much of it they show. YouTube honors VTT positioning but keeps only bold, italic and underline.
Basic SRT has no positioning at all. Some players read <i> and <b> tags in an SRT, but YouTube’s help says it ignores style markup in SRT files. If an SRT subtitle lands on top of on-screen text, the fix goes in the edit or in the timing.
Which one to send where
| Destination | What to send |
|---|---|
| YouTube | Either. SRT in its basic form, saved as plain UTF-8, or VTT if a subtitle needs to move |
| Vimeo | Either, and Vimeo recommends WebVTT |
| SRT | |
| Video ads on Facebook and Instagram | SRT, named after the video with a language and country code |
| Your own website (HTML5 player) | VTT |
| Back to an editor | SRT is the safe bet, since VTT import depends on the program and version |
| Streaming or broadcast | Whatever the delivery spec names |
The website row is the strict one. The <track> element that browsers use for subtitles on a <video> reads WebVTT and won’t load an SRT.
For video ads, Meta’s help gives the naming rule with an example: a video called ice_cream_ad with US English captions needs a file named ice_cream_ad.en_US.srt, and a file named any other way is rejected.
Some social apps have nowhere to upload a subtitle file. They make their own captions or expect the text burned into the picture, so they get a subtitled export.
Streaming and broadcast specs usually ask for XML formats from the TTML family (Netflix publishes its own IMSC 1.1 profile, for example) or broadcast caption formats such as SCC.
When a spec names a format, deliver that one. The final QC checklist covers the rest of what a spec tends to ask for.
Encoding: why accents break
A subtitle file is text saved in some encoding, and the one to use is UTF-8. YouTube asks for plain UTF-8 in SRT files, Vimeo says caption files must be UTF-8 for special characters to display correctly, and the WebVTT spec requires it.
Trouble starts when the file passes through a program that saves in an older encoding, often Windows-1252. Open a UTF-8 file as Windows-1252 and “José” becomes “José”. Go the other way and you get “Jos�”.
English subtitles can hide the problem until a name like José turns up, while in Portuguese or Spanish it’s on almost every line.
It usually happens after a translator or a client has edited the file in an old text editor.
Check the accents in any file that has been through other hands before you upload it, and if they’re broken, reopen it in the encoding it was saved in and save it as UTF-8.
Line breaks and the two-line limit
In both formats, the line breaks inside a subtitle are the ones written in the file. A line too long for the screen gets wrapped by the player wherever it runs out of room, so a two-line subtitle can end up as three lines with one word alone on the last.
A blank line ends the subtitle, so an empty line in the middle of the text (usually someone pressing Enter twice while editing by hand) cuts it short, and the rest is dropped or shows up broken.
Line length, reading speed and where to break a sentence work the same way in SRT and VTT. They’re covered in our subtitle guidelines, where 42 characters per line and two lines at most is the common benchmark.
Converting between them, and the usual mistakes
From SRT to VTT, add WEBVTT and a blank line at the top, then change the comma before the milliseconds to a dot on every timing line. Leave the text alone, since a comma there is just a comma.
The numbers can stay. Save the result as UTF-8 with the .vtt extension.
From VTT to SRT there’s more to take out. Remove the header and any STYLE or NOTE blocks, delete the cue settings after the timings and add the hours where they were left out.
Then change the dots to commas, number the subtitles from 1 and strip any tags an SRT reader won’t know. Positions you set in VTT are lost along the way.
Most subtitle editors do either conversion in one step. Check the result anyway, because rejected files fail for the same few reasons:
- An .srt renamed to .vtt. Without the WEBVTT line the browser refuses the file, and a subtitle with a comma in its timing gets skipped.
- Subtitles made for an earlier cut. If a shot was trimmed or moved after the file was made, every subtitle after that point is off, so export them from the version you’re actually delivering.
- A file name the platform can’t read. For Meta’s ads the SRT takes the video’s name plus a language and country code, so
ACM_014_teaser_v03.mp4pairs withACM_014_teaser_v03.en_US.srt. If your videos follow a naming convention, the subtitle file inherits it.
How this works in RecReview
In RecReview you transcribe a video in Portuguese, English or Spanish, or let it detect the language from the speech.
The subtitles are built from that transcript with up to 42 characters per line and two lines at most, and you turn them on in the player with the CC button.
The transcript panel next to the player has a download menu with SRT, VTT, TXT and JSON. The SRT and VTT carry the subtitles the player shows, including any text an owner, admin or editor fixed by clicking on a subtitle.
The SRT numbers each subtitle from 1 and puts a comma before the milliseconds, and the VTT opens with WEBVTT and uses a dot. Both are saved as UTF-8, so accents come out intact.
The VTT has no position or style settings, which leaves the placement to the player.
Each version has its own transcript and subtitles, so you download them from the version you’re delivering. TXT gives the transcript with a timestamp on each passage, and JSON gives every word with its timing.
Clients can download the same files from the client portal under the same rule as the video: once the task is marked as delivered, or earlier if you allow downloads before approval for that client.
