WebVTT has a W3C specification. SRT does not have a specification at all. Most comparisons present them as two competing standards, which is the single most misleading thing you can say about them — and it is the reason the practical differences look arbitrary until you know.
SubRip Text came from a piece of software called SubRip. It spread because it was simple and everyone copied it. There is no standards body document to point at, no normative requirements, no conformance criteria. What SRT "is" is whatever the ecosystem has converged on.
WebVTT is the opposite. It is a W3C document — currently a Candidate Recommendation Draft, dated 20 May 2026 — with requirements written down in testable language.
Once you see that asymmetry, the rest of this stops being a list of trivia.
What the specification actually requires
Three requirements from the WebVTT spec are worth quoting, because each one causes a specific real-world failure when ignored.
Encoding and MIME type (§4.1):
"A WebVTT file must consist of a WebVTT file body encoded as UTF-8 and labeled with the MIME type
text/vtt."
Two requirements in one sentence, and the second is the one that bites. A perfectly valid .vtt file served as text/plain can be rejected by the browser's <track> element. If your captions are silently not appearing on a web page and the file looks right, check the Content-Type your server is sending before you touch the file.
The timestamp separator (§4.1):
"Two ASCII digits, representing the seconds as a base ten integer in the range 0 ≤ seconds ≤ 59. A U+002E FULL STOP character (.). Three ASCII digits, representing the thousandths of a second"
A full stop. Not a comma. SRT uses a comma. This is the reason renaming subtitles.srt to subtitles.vtt does not work — the files differ at the byte level in every single timestamp line, and a parser reading to spec will reject them.
Cue identifiers are optional (§4.1):
"Optionally, a WebVTT cue identifier followed by a WebVTT line terminator"
In SRT, the numbering is load-bearing structure. In WebVTT it is optional and may be absent entirely. This matters when converting in the VTT → SRT direction: you cannot rely on the source file having numbers, so they have to be generated.
Converting, and what it costs in each direction
The two directions are not symmetric, and nobody tells you which one loses data.
SRT → VTT is lossless. Add the WEBVTT header, change every timestamp comma to a full stop, leave the rest alone. Everything SRT can express, WebVTT can express.
VTT → SRT is lossy, in specific and enumerable ways. Going by what our own converter does — and it has to do this, because the target format cannot hold the data:
STYLE,REGIONandNOTEblocks are dropped entirely.- Cue settings — the
position,line,alignvalues that appear after the-->— are discarded. - Cue identifiers are thrown away and replaced with sequential numbering.
Point 2 is the one people notice later. If your VTT positioned captions at the top of the frame to avoid covering on-screen text, that instruction does not survive. The words arrive; the placement does not. This is not a shortcoming of any particular converter — SRT has nowhere to put that information.
So the rule of thumb is: convert SRT → VTT freely; convert VTT → SRT only when you know the file has no styling or positioning you care about.
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
This runs in your browser — the file is read locally and converted locally, which for a subtitle file containing an unreleased script is not a trivial detail. For the other direction, VTT to SRT does the same job with the caveats above.
The two encoding rules people skip
Both halves of that MIME-and-encoding sentence are enforceable, and they fail in different ways.
UTF-8 is required, not recommended. A caption file saved in a legacy regional encoding may open perfectly in a text editor on the machine that made it, and arrive as mojibake everywhere else. This is disproportionately a problem for languages with accented characters and for anything non-Latin, and it tends to surface only after the file has been handed to someone else. If your captions display but the characters are wrong, the encoding is the place to look — the timings will be perfect, which is what makes it confusing.
text/vtt is a server configuration, not a file property. You cannot fix this by editing the file, because nothing is wrong with the file. Whatever serves it has to be configured to send the right Content-Type, and plenty of static hosts do not know the .vtt extension out of the box. The symptom is distinctive: the network request for the file succeeds with a 200, and the captions still never appear.
Neither of these has an equivalent in SRT — not because SRT handles them better, but because SRT has no specification to state requirements in. Nothing is required, so nothing can be violated, and the file either happens to work with a given tool or happens not to.
Which one should you actually use
Use SRT when the file is going into an upload form. YouTube, most social platforms, most video editors and most desktop players accept it, and it is the safest thing to hand to a system you do not control. Its lack of a specification is a weakness technically and a strength practically — it is so simple that nearly everything can parse it.
Use VTT when the captions play on the web through an HTML5 <video> element, or when you need positioning and styling. The <track> element reads WebVTT; it does not read SRT. If you are building the page, this decision is made for you.
Keep the VTT as your master if you have both. Since SRT → VTT is lossless and VTT → SRT is not, the richer format is the one to keep, and you generate SRT from it as needed rather than the reverse.
Why SRT files behave inconsistently
This follows directly from the opening point, and it is worth stating explicitly because it saves a lot of confused debugging.
Because SRT has no specification, there is no authority to say whether a given file is valid. Different tools have quietly extended it in different directions — some accept HTML-ish tags for bold and italic, some accept positioning coordinates on the timestamp line, some tolerate missing cue numbers, some do not. Two tools can disagree about the same file and neither is wrong, because there is nothing to be wrong against.
When a subtitle file works in VLC and fails on upload, this is usually why. The producing tool used an extension the consuming tool never adopted. There is no fix beyond simplifying the file to the common subset — which is, in effect, what a conversion pass does.
WebVTT does not have this problem to the same degree, because there is a document that settles disagreements.
FAQ
Can I just rename a .srt file to .vtt?
No. WebVTT requires a WEBVTT header line and uses a full stop before the milliseconds, while SRT uses a comma. Renaming changes neither, so a conforming parser rejects the file. Convert it properly.
Is WebVTT an official standard? It is a W3C document, currently at Candidate Recommendation Draft status dated 20 May 2026 — inside the standards process rather than finalised. That is still dramatically more formal than SRT, which has no specification of any kind.
Does converting VTT to SRT lose anything? Yes: styling blocks, region definitions, notes, cue positioning settings, and cue identifiers. Plain text and timings survive. Going the other way, SRT to VTT, loses nothing.
Why do my captions not show up on my website?
Check the Content-Type header first. The spec requires WebVTT files to be labeled text/vtt, and a server sending text/plain is a common cause of a valid file being ignored by the <track> element.
Which format does YouTube want? Both are accepted. SRT is the more conservative choice for any upload form, since it is the format with the widest support.
Specification quotes from the W3C WebVTT specification, checked 16 September 2026; status and content can change. Conversion behaviour described is that of Clapr's own converter — see all Clapr tools. To burn subtitles permanently into the picture instead, see burn subtitles to video.
