How to convert SRT to VTT
Two formats, one real difference — and one reason the web needs the second one.
If you have put an SRT file into an HTML5 video element and watched nothing happen, this is why: browsers do not support SRT. The <track> element takes WebVTT and only WebVTT. The conversion is small, which is a good thing — it means nothing gets lost on the way.
Open the subtitle editor → Open your SRT with "Open an SRT or VTT", then Export VTT.- 100% freeNo account, no minute quota, no paid tier.
- Nothing is uploadedYour video is read on your device and never reaches a server.
- No catch on the outputNo watermark, no length cap, no locked export formats.
- Updated in the openEvery fix is written down on the changelog page.
How to convert
Open the editor, use Open an SRT or VTT, pick your file, then click Export VTT. That is the whole operation, and it happens in your browser — the file is not uploaded anywhere.
Converting through an editor rather than a one-shot converter has a side benefit: you can see the file. Broken timings, overlapping lines and mojibake from a bad encoding are all visible before you ship the file, and the reading-speed and overlap flags will point at the lines that were already wrong in the original.
What actually changes
Three things. The file gains a WEBVTT header line at the top. The decimal separator in timestamps changes from a comma to a period — 00:00:02,350 becomes 00:00:02.350. And the sequence numbers, which SRT requires and VTT treats as optional cue identifiers, are usually dropped.
That is genuinely all of it for ordinary subtitles. Both formats carry the same thing: a start time, an end time, and some lines of text. Everything beyond that — positioning, styling, regions — exists in VTT and not in SRT, so converting the other direction is where you can lose information, not this direction.
Why the web insists on VTT
WebVTT was designed for the web rather than adapted to it. It is UTF-8 by definition, which removes the encoding guesswork that makes SRT files show question marks and boxes. It has a defined cue-settings syntax for placing text on the picture, a styling model that hooks into CSS, and a JavaScript API through the TextTrack interface so a page can read and react to cues.
None of that exists in SRT, which was a subtitle format for a Windows program in the nineteen-nineties and became universal by being simple. That simplicity is exactly why it is still the right thing to hand to a platform, and why the web needed something else.
Using the result
In HTML, add a track element inside your video: give it the .vtt file, a kind of "captions" or "subtitles", the srclang, and default if you want it on from the start. One thing catches people out — the file must be served from the same origin as the page, or with CORS headers, and with a text/vtt content type. A VTT served as text/plain from another domain will silently do nothing.
For HLS streaming, VTT is the subtitle format in the specification, delivered as segmented files referenced from the playlist. If you are going the other way and need VTT back as SRT, that conversion is here too.
Frequently asked questions
Does converting lose anything?
Going SRT to VTT, no. Going the other way can, because VTT supports positioning and styling that SRT has nowhere to store.
Why does my VTT not show in the browser?
Usually the content type or CORS. The file must be served as text/vtt, and from the same origin as the page or with the right CORS headers. The WEBVTT header line must also be the first thing in the file.
Can I just rename the file?
No. The header line and the timestamp separator both have to change, and a renamed SRT will be rejected.
Is the file uploaded to convert it?
No. It is read and written by the page in your browser.