SRT vs VTT vs TXT: which subtitle format to use

SRT vs VTT is the question people ask at one of two moments: when a caption file refuses to load, or when an upload dialog demands one format and the tool in front of them only offers another. The short answer is that both formats carry the same words and the same in and out times. The difference is what else each one is allowed to carry, and how strictly the thing reading it checks the file.

TXT joins the comparison for a different reason. It is what people pick when the words matter and the clock does not: a blog draft, a set of pull quotes, a translation brief, a search index, a set of notes. It is not a subtitle file and cannot be used as one, because it holds no timing whatsoever. Half the confusion in this topic comes from treating those three as three quality levels of the same thing rather than three containers with different shelves inside.

What follows is a reference. It shows the exact shape of an SRT cue and a WebVTT cue, lists every caption file type YouTube accepts on upload with what each one supports, and marks which conversions are safe and which discard data you cannot get back. One disclosure up front: YouTubeScribe is our product, and it exports all three of these formats, so read the product notes near the end knowing that.

What each subtitle format actually carries

A subtitle file is a list of cues. A cue is a start time, an end time, and some text that should be on screen between the two. Everything that separates SRT from VTT from TXT is either a field wrapped around that cue, or the absence of the cue altogether.

Hold that definition while you read the rest of this page. Most format arguments online are really arguments about fields nobody in the conversation needed. If your file has to put a line on screen at 4.5 seconds and take it off at 7.2 seconds, every format below except TXT does that job identically.

SRT: the plain timed format

SubRip, saved with a .srt extension, came out of a Windows program that pulled subtitles off DVDs in the early 2000s. It never had a standards body and it still does not have a formal specification in the way HTML or WebVTT does. What it has instead is support almost everywhere, because the file is simple enough that writing a parser for it is an afternoon of work.

An SRT file is a run of numbered cues separated by blank lines. Every cue has a number, a timing line, and one or more lines of text. Nothing else is defined. There is no official place to put a speaker name, no official way to move a line to the top of the frame, and no official styling. Some players will honour bold and italic tags borrowed from HTML, and plenty of others will print the tags on screen or drop them. YouTube's own documentation is blunt about it: .srt is treated as plain UTF-8 text with no styling markup.

That plainness is the reason SRT survived. A format with no optional features has no optional features to get wrong. If somebody asks for a subtitle file and does not say which kind, they almost always mean this one.

VTT: the web format with room to spare

WebVTT stands for Web Video Text Tracks and it is a W3C specification. It was written for HTML5 video and web playback, which shows in every design decision inside it. Browsers parse it natively. You point a text track element at a .vtt file and the browser handles the rest, including switching between language tracks and honouring the user's caption settings.

Because it was specified rather than reverse engineered, WebVTT has room for things SRT never had. A cue can have an identifier on its own line so scripts can address it. The timing line can carry cue settings that control where the line sits and how it aligns. The file can hold comment blocks that parsers skip. Text inside a cue can carry voice spans that tag a line with a speaker name, plus class spans, ruby annotations and timestamps for karaoke style highlighting. The header area can declare style blocks and region blocks that apply across the file.

In a browser you can also style cues with CSS through the cue pseudo-element, which is the only way to change caption typography on your own player without building a custom renderer. None of that reaches YouTube. On a YouTube upload, WebVTT positioning is supported and styling is limited to bold, italic and underline. The rest of the specification is there for the players you control.

TXT: the words with the clock removed

TXT is not a subtitle format. There is no specification, no cue structure and no timing. It is a text file, and the only thing that makes one TXT export better than another is how the exporter decided to break lines and whether it kept speaker labels.

Some tools write a timestamp in square brackets at the start of each paragraph. That is a house convention, not a format. A player will not read it. A person will, which is the whole point: TXT exists so a human can paste the words into a document, a translation memory, a summariser or a search box without stepping over timing syntax on every line.

One row of that table decides most cases. If something must show a line at a given second, do not send TXT. If a human is going to read and rewrite the words, do not send SRT and expect them to enjoy it.

The cue shapes, line by line

This is the part worth memorising, because once you know what a valid cue looks like you can diagnose a broken file by eye in about five seconds.

An SRT cue

An SRT cue is three parts stacked in a fixed order, then a blank line.

• The number line. A plain integer on its own. The first cue is 1, the second is 2, and they run in order with no gaps. Some players tolerate out of order numbers and some do not, so keep them tidy.
• The timing line. It reads 00:00:01,200 --> 00:00:04,500. Hours, minutes, seconds, then a comma and exactly three digits of milliseconds, on both sides of the arrow. The arrow is two hyphens and a greater-than sign with a space either side. Hours are not optional in SRT: 01:200 --> 04:500 is not a valid timing line.
• The text lines. One line, or two, or occasionally three. The cue ends where the blank line starts, so a stray blank line inside your caption text truncates the cue.
• A blank line. This is structural, not decorative. It is how the parser knows the cue finished and the next number line is coming.

Put together, one cue reads as the number 1, then the line 00:00:01,200 --> 00:00:04,500, then the caption text, then an empty line before the number 2. A whole SRT file is that block repeated until the video runs out. Save it as UTF-8. A byte order mark at the top of the file is the classic reason a first cue vanishes, because some parsers read the invisible bytes as part of the number 1 and reject the cue.

A WebVTT cue

A WebVTT file has a header before the cues start, and its cues have one extra optional line.

• The first line of the file is WEBVTT. The specification allows an optional byte order mark before it and allows extra text after it on the same line, but nothing else may come first. No blank lines above it, no comments above it, no stray characters.
• A blank line, then the cues. Style and region blocks, if you use them, sit in this header area before the first cue.
• An optional cue identifier on its own line above the timing line. It can be a number, which is why an SRT file that keeps its cue numbers is still legal WebVTT after the other edits.
• The timing line. It reads 00:00:01.200 --> 00:00:04.500. Same clock, dot instead of comma. WebVTT lets you drop the hours component when it is zero, so 00:01.200 --> 00:04.500 is valid here and would be invalid in SRT.
• Optional cue settings after the end timestamp on the same line, separated by spaces. Things like line, position, align and size. This is where placement lives.
• The text lines, then a blank line, exactly as in SRT.

Comment blocks start with the word NOTE and are skipped by parsers, which makes them useful for leaving instructions for the next editor without polluting the captions. Overlapping cues are legal in WebVTT and the specification says what a player should do about them. In SRT overlapping cues are technically writable but behaviour varies by player, so avoid them unless you have tested the destination.

The comma and the dot

The failure mode differs by player. A strict WebVTT parser that hits a comma in a timestamp treats the line as not a timing line, so the cue never registers and the track silently plays empty. Some SRT parsers are looser and will accept a dot; plenty of editors will not, and will report a generic import error that names no line number. Neither tells you what is actually wrong, which is why this one character eats so many hours.

What a TXT export looks like

There is nothing structural to show, and that is exactly the point. A TXT export is paragraphs. The useful decisions are how aggressively short cues are joined back into sentences, whether speaker labels survive, and whether the exporter left a bracketed timestamp at the head of each paragraph as a reading aid. None of that is machine readable timing. It is a document.

Which players and platforms accept which

Format choice is usually decided by the destination, not by preference. So start with the destination. YouTube accepts a long list of caption file types on upload, and the list is more interesting than people expect, because it tells you exactly which features survive ingest for each one.

Read that table twice if you have ever been told that YouTube strips WebVTT placement. It does not. Positioning is the feature WebVTT keeps on YouTube, and styling is the feature it loses down to three tags. SRT keeps neither, because YouTube treats it as plain text by design.

Note also that .cap appears three times, against three unrelated formats. The extension tells a player almost nothing. This is worth remembering the next time you consider fixing a file by typing a different extension after the dot.

Everywhere else you will send a caption file

• Browsers and any HTML video player: WebVTT, delivered through a text track element. Browsers do not parse SRT natively, so an SRT file pointed at a track element does nothing at all.
• Facebook: SRT. It accepts the file and strips formatting tags out of it, so any bold or italic you smuggled in will not appear.
• YouTube: SRT and WebVTT both work, along with everything in the table above. For most creators SRT is the path of least friction and WebVTT is the path if you need a line moved off a lower third.
• Video editors such as Premiere Pro and DaVinci Resolve: SRT first. Several accept WebVTT too, and support has improved, but SRT is the version that has never once been rejected.
• Broadcast and compliance deliverables: SCC, STL and the other CEA-608 formats. If a spec sheet mentions 608 or 708, an SRT is not going to satisfy it no matter how clean the timings are.
• Course platforms, webinar tools and internal video portals: check the upload dialog. Most take SRT, many take VTT, and a few silently accept both and convert one into the other.

One server-side detail bites people who host their own video. A .vtt file must be served with the text/vtt media type. Serve it as text/plain or, worse, as an HTML error page with a 200 status, and the browser will fetch the file, fail to parse it, and give you an empty track with no console error worth reading. If the track file lives on a different origin from the page, it also needs the right cross-origin headers and a crossorigin attribute on the video element.

The boring failures that have nothing to do with format

A surprising share of rejected caption files are perfectly valid SRT or VTT that fell over on something unrelated to the format war. Four to check before you blame the container:

• Encoding. Save as UTF-8. A file written in a legacy code page will import, and then every accented character and every curly quote will come out as garbage. This is the number one cause of captions that look fine in English and broken in every other language.
• Byte order marks. Harmless in WebVTT, which explicitly permits one, and a common cause of a missing first cue in SRT. If your first caption never appears, strip the mark and re-import.
• Language codes. Most upload dialogs ask you to declare a language separately from the file. Getting that wrong does not corrupt anything, it just files your English captions under the wrong track and hides them from the viewers who needed them.
• Line length. Neither format limits it, and every human reading limit does. Two lines of roughly forty characters is the working convention for on-screen captions. A single ninety character line is technically valid and practically unreadable on a phone.

Converting between the three without breaking anything

Two of the three conversions are cheap. One of them is permanent. Knowing which is which saves a lot of re-work.

SRT to VTT

This is a small text edit, not a real conversion, because the two formats hold the same data. Four steps:

1. Put WEBVTT on the very first line of the file, then leave one blank line under it.
2. Change the millisecond separator from a comma to a dot on both sides of every timing arrow. 00:00:01,200 --> 00:00:04,500 becomes 00:00:01.200 --> 00:00:04.500. This is the step people forget.
3. Leave the cue numbers alone or delete them. WebVTT reads a bare number line above a timing line as a cue identifier, which is legal, so both choices produce a valid file.
4. Save as UTF-8 with a .vtt extension. Either line ending style is accepted by WebVTT parsers, so you do not need to convert between Windows and Unix line breaks.

What you do not gain is anything WebVTT could have carried. Converting an SRT to VTT does not add placement, voices or styling, because none of that was in the source. You end up with a valid WebVTT file that happens to use none of WebVTT's extra features, which is fine and extremely common.

VTT to SRT

This direction loses whatever the VTT file was using beyond plain timed text. Work down the list:

1. Delete the WEBVTT line and anything else sitting in the header area, including style and region blocks.
2. Delete every NOTE comment block. SRT has no comment syntax, so leaving them in turns your notes into on-screen captions.
3. Delete the cue settings that follow the end timestamp. Placement does not survive the trip.
4. Replace voice spans with plain text, or convert them into a speaker prefix such as a name followed by a colon at the head of the line.
5. Change every dot in a timestamp back to a comma, and add the hours component back if the VTT file omitted it.
6. Number the cues from 1 in order, since SRT requires the number line that WebVTT made optional.

The words and the timings come through untouched. The lost items are placement, regions, comments, voice tagging and any CSS you had styling the cues. If those mattered, keep the VTT as your master file and treat the SRT as a derived export rather than a replacement.

Anything to TXT

Converting SRT or VTT to TXT is lossy on purpose. The cue numbers and the timestamps are discarded and there is no way to recover them from the resulting text file. Nothing in the TXT records when a word was spoken, so getting timings back means re-timing from scratch: either a person with a scrub bar and a lot of patience, or a forced aligner run against the original audio. Both are real work. Neither is a button.

Renaming a file does not convert it

Renaming transcript.txt to transcript.srt does not create an SRT file. The extension is a label for humans and a hint for operating systems. The format is the bytes inside: the number line, the timing line with its arrow, the blank line between cues. A player handed a renamed text file will report a parse error, or show nothing and look broken, which is worse because you will spend the next twenty minutes debugging the player.

The same goes in the other direction. A file that is genuinely valid SRT stays valid SRT when you rename it to .txt, and a player that reads by content rather than by name may still parse it. Extensions describe intent. They do not change data.

Here is the same set of conversions as a single table, since this is the part people come back to check.

If a caption file is refused, read the first line of the file and the first timing line before you read anything else. Almost every failure lives in one of those two places.

Priya Raman, YouTubeScribe

Choosing a format, and what we export

Most of the time this decision takes ten seconds and does not deserve more.

• The destination named a format in its upload dialog. Send that one. Do not argue with an upload dialog.
• Nobody named a format, but a player or an editor has to put a line on screen at a given second. Send SRT. It is the most widely accepted timed file in existence.
• The file will sit next to an HTML video element, or you need lines placed away from the default position, or you want speakers tagged. Send VTT.
• A human is going to read, rewrite, translate, summarise or index the words. Send TXT, and keep a timed file beside it.
• The deliverable spec mentions CEA-608, 708, or a broadcast standard. You are in SCC or STL territory and neither SRT nor VTT will pass review.

If you want a single default that survives most days: export SRT and TXT together. One goes to the player, the other goes to the person. You will be right far more often than you are wrong, and when you are wrong the fix is the four-line edit in the section above.

There is one habit worth building on top of that. Decide which file is your master and stick to it. If any part of your workflow uses placement, speakers or styling, the VTT is the master and everything else is a derived copy you can regenerate. If nothing does, the SRT is the master and the VTT is a four-line edit away whenever a web player asks for one. What you want to avoid is two half-edited files with different corrections in each, which is how caption drift starts and how the wrong version ends up published.

What YouTubeScribe does with each format

Worth restating plainly, since this page is on our own site. YouTubeScribe reads a caption track that already exists on a public or unlisted video. It never invents speech. If YouTube never wrote a track for that video, there is nothing for us to convert into any format, and we say so rather than handing back an empty file.

The Subtitle Downloader at /tools/subtitle-downloader is the tool for this job. It is where SRT and VTT come out, with the timing intact from the track YouTube served. If what you actually want is the words in a document, the Transcript Generator is the shorter path, because it skips the caption syntax entirely.

On SRT and VTT the cue boundaries stay close to what YouTube sent. We are not rewriting the timing, we are writing the same cues into the syntax the format requires. TXT is treated differently: it may merge cues more aggressively, because a person is reading it and three-word fragments on separate lines make for miserable reading.

On pricing, TXT and SRT are free. VTT sits on Pro, because the extra fields in WebVTT are mostly used by teams shipping a player rather than by someone who just wanted the words out of a video. If you are not building a player, SRT will almost certainly do the job you have.

One last note on quality, since it comes up constantly. No format improves accuracy. If the caption track has a misheard word, that word is misheard in the TXT, in the SRT and in the VTT identically. Formats decide what a file can carry. They have no opinion about what was said.

Questions people ask

Sources

1. YouTube Help. Use automatic captioning. support.google.com· Checked 17 August 2026.
2. YouTube Help. Supported subtitle and caption files. support.google.com· Checked 17 August 2026.
3. YouTube Help. Add subtitles and captions. support.google.com· Checked 17 August 2026.
4. W3C. WebVTT: The Web Video Text Tracks Format. w3.org· Checked 17 August 2026.
5. Google for Developers. YouTube Data API: Captions. developers.google.com· Checked 17 August 2026.
6. W3C. Timed Text Markup Language 2 (TTML2). w3.org· Checked 17 August 2026.
7. W3C. Timed Text Markup Language 1 (TTML1). w3.org· Checked 17 August 2026.
8. W3C. TTML Profiles for Internet Media Subtitles and Captions 1.1. w3.org· Checked 17 August 2026.
9. MDN Web Docs. WebVTT API. developer.mozilla.org· Checked 17 August 2026.
10. MDN Web Docs. The Embed Text Track element. developer.mozilla.org· Checked 17 August 2026.
11. MDN Web Docs. VTTCue. developer.mozilla.org· Checked 17 August 2026.
12. IANA. Media Types registry: text/vtt. iana.org· Checked 17 August 2026.
13. Google for Developers. YouTube Data API: captions.insert. developers.google.com· Checked 17 August 2026.
14. Wikipedia. SubRip. en.wikipedia.org· Checked 17 August 2026.
15. Wikipedia. WebVTT. en.wikipedia.org· Checked 17 August 2026.
16. Wikipedia. Timed Text Markup Language. en.wikipedia.org· Checked 17 August 2026.
17. Wikipedia. EIA-608. en.wikipedia.org· Checked 17 August 2026.
18. AssemblyAI. Subtitle file formats explained. assemblyai.com· Checked 17 August 2026.
19. Ditto Transcripts. SRT vs VTT: understanding the difference between subtitle formats for captions. dittotranscripts.com· Checked 17 August 2026.
20. Subly. SRT vs VTT. getsubly.com· Checked 17 August 2026.

Reviewed on 17 August 2026. If a line is wrong, email support@youtubescribe.com.