SRT vs VTT vs plain text: which export do you need?

Every transcription tool offers the same three downloads and explains none of them. The choice comes down to one question: does anything need to stay in sync with the audio? If yes, you want SRT for a video platform and VTT for video on your own web page. If no, take the plain text. The rest of this post is what a cue actually is, what each format can and cannot carry, and what breaks when a player gets the wrong one.

A cue is a start time, an end time and a line or two of text

Subtitles are not a ribbon of text laid over a video. They are a list of cues. A cue is one block: when it appears, when it goes away, and the words in between. Everything else in a subtitle format is bookkeeping around that. Here are two cues in SRT:

1
00:00:04,000 --> 00:00:07,400
Thanks for making the time.

2
00:00:07,480 --> 00:00:11,200
I want to start with the part
you said was messy.

The Matroska project describes SubRip as four components: a number saying which subtitle this is in the sequence, the time it appears and disappears, the subtitle itself, and a blank line marking the start of the next one. That is the whole format, and Matroska calls it “perhaps the most basic of all subtitle formats”.

WebVTT builds a cue from the same parts. The W3C specification makes the identifier optional, so a cue can begin straight at its timings line, and it allows a settings string after the end time saying where on screen the cue belongs.

A transcript with timing is a list of these blocks. A transcript without timing is the payloads with everything else thrown away, which is the real difference between the three downloads.

SRT is the same four lines repeated, with no styling

SubRip is the format to reach for when someone else’s player has to read the file. YouTube lists it first among the caption files it accepts and recommends it, with SubViewer, to anyone new to captioning, because these files carry only basic timing information and open in any plain text editor.

The comma in the timestamp is not a typo. SRT writes HH:MM:SS,mmm with a comma before the milliseconds, and some players reject a full stop outright.

The thing to understand about SRT is what it does not have. There is no positioning: the player decides where the text sits, usually centred at the bottom, and nothing in the file can argue. No colour, no font, no region. YouTube’s page is blunt about markup in SRT uploads, saying no style information is recognised and the file must be plain UTF-8. Many desktop players render <i> and <b> anyway, which is what makes this confusing: the same file comes out italic in one place and with the literal tags on screen in another.

That poverty is why SRT travels. There is almost nothing for a parser to disagree about.

VTT is the file browsers actually load, and it has room for settings

WebVTT is SRT with somewhere to grow. The W3C specification requires the file to begin with the string WEBVTT, uses a full stop before the three-digit milliseconds, and treats the cue identifiers as optional. What you get in exchange is a set of controls SRT has no room for:

• Cue settings on the timings line: line for vertical placement, position for horizontal, size for the cue box width, align for the text inside it, vertical for top-to-bottom writing.
• STYLE blocks carrying CSS inside the file, the ::cue pseudo-element, and named colour classes including white, lime, cyan, red, yellow, magenta, blue and black.
• REGION blocks defining a named area of the screen with its own width, anchoring and scroll behaviour.
• NOTE blocks, comments the parser ignores.
• Inline tags: <i>, <b>, <u>, <c> for a class span, <v> for a named voice, <lang> for a language switch, ruby annotations.

The other half of the case for VTT is that browsers give you no choice. MDN’s reference for the HTML <track> element says the tracks are formatted in WebVTT, .vtt files, and says nothing about SubRip. Point a <track> at an SRT and you get no captions.

Platforms honour less of the format than browsers do. YouTube accepts WebVTT but calls it an initial implementation, with positioning supported and styling limited to <b>, <i> and <u>.

What breaks when a player gets the wrong file

Most format failures are quiet. Nothing errors, the captions are simply not there.

The commonest is the timestamp separator. A full stop where a comma belongs is valid WebVTT and invalid SubRip. Strict parsers drop the file, lenient ones take it, and you find out which after uploading.

The second is the header. Hand a VTT to something expecting SRT and the parser reads the word WEBVTT where a cue number should be. Some players show one broken subtitle, some show none.

The third is the blank line. Both formats use it as the block separator, and the W3C spec is explicit that one or more line terminators must sit between blocks. Delete one and the parser reads the next cue number as dialogue, and the file is off by one for the rest of the recording. That looks like a timing problem and is not.

The fourth is encoding. YouTube requires plain UTF-8. A file saved as Windows-1252 turns curly apostrophes and accented letters into ’ and é, and the damage sits in the file rather than the player.

If the captions appear but slide out of sync as the video runs, none of the above is your problem. That is a frame rate or offset issue, and subtitle timing drift covers it.

The line and character conventions both formats inherit

Neither format limits how much text a cue may hold. A paragraph in one cue is perfectly valid and perfectly unreadable. The conventions come from the style guides instead.

Netflix’s English timed text style guide sets 42 characters per line and a maximum of two lines, and caps reading speed at 20 characters per second for adult programmes and 17 for children’s. Its separate timing guidelines say a subtitle should not be shorter than 20 frames, which it gives as four fifths of a second, and that there must be a minimum of two frames between subtitles, roughly 80 milliseconds at ordinary frame rates. It also describes chaining, where gaps under half a second are closed to exactly two frames.

Our exporter builds to 42 characters a line, two lines a cue, one to six seconds on screen and an 80 millisecond gap, for both SRT and VTT. If you write cues by hand, those are the numbers to hold yourself to, and how to make an SRT file has the mechanics.

Plain text throws the timing away, and you cannot get it back

A .txt file is the whole transcript with no timing. Use it when the transcript itself is the deliverable: meeting notes, quotes for an article, a draft you are going to rewrite anyway. It pastes cleanly into any editor and search works the way you expect.

What you lose is more than the timestamps. You lose the cue boundaries, which were reading decisions about where one thought ends, and the line breaks inside each cue, chosen to keep a name from splitting across two lines. And you lose any way back: timings cannot be inferred from words, they have to be measured against audio, so going from TXT to subtitles means transcribing the file again or hand-timing it against the waveform.

Which export to download

Publishing to a platform, use SRT. Publishing on your own page, use VTT. Everything else, plain text.

SRT and VTT are close enough that conversion is a header line and a search and replace in the timestamps. The only thing lost going from VTT to SRT is styling and positioning, which most files never had.

The cheap move is not to choose. Run the file through the transcriber and take SRT and TXT from the same pass, which costs one more click and saves you the afternoon where you find out the timing is gone. It runs OpenAI’s open-source Whisper model on your own graphics card in desktop Chrome or Edge, English only for now, so read the transcript through before you publish it.

Frequently asked questions

Can I rename a .srt to .vtt and be done? No. The extension is the least of it. A WebVTT file has to start with the WEBVTT line and its timestamps need full stops before the milliseconds rather than commas. Rename without those two edits and a browser loads a file it cannot parse.

Does YouTube take VTT as well as SRT? Yes. YouTube lists WebVTT among the supported formats, while describing it as in initial implementation with positioning supported and styling limited to bold, italic and underline. For a straightforward upload it recommends SubRip to anyone starting out.

Which file should I keep once the video is published? The SRT, next to the video file. It is small, it is plain text, and everything else is derivable from it. The TXT is a two-minute job from the SRT, and the reverse is not.

Sources, checked 15 September 2026

• https://www.w3.org/TR/webvtt1/ : W3C WebVTT specification (header, cue settings, STYLE, REGION, NOTE, inline tags, blank lines)
• https://www.matroska.org/technical/subtitles.html : Matroska on subtitle formats (the four components of a SubRip cue)
• https://support.google.com/youtube/answer/2734698 : YouTube Help, supported subtitle files (SubRip recommended, no markup in SRT, plain UTF-8, WebVTT styling limits)
• https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/track : MDN on the HTML <track> element (tracks are WebVTT)
• https://partnerhelp.netflixstudios.com/hc/en-us/articles/217350977-English-USA-Timed-Text-Style-Guide : Netflix style guide (42 characters, two lines, 20 and 17 characters per second)
• https://partnerhelp.netflixstudios.com/hc/en-us/articles/360051554394-Timed-Text-Style-Guide-Subtitle-Timing-Guidelines : Netflix timing guidelines (20 frames, two-frame gap, chaining)
• Our cue-building numbers come from the exporter on this site