SRT to VTT
Or paste subtitle text
What this conversion changes
Nothing is lost in this direction — every feature of the source format has somewhere to go in the target format.
This list comes from the capability matrix for these two formats, not from the particular file you loaded. A specific file may lose more if it uses features the format allows but the matrix does not model.
SRT and WebVTT carry the same subtitles in different wrappers, and this page moves a file from one to the other. The timeline, the cue text, the line breaks and any inline formatting survive unchanged; what changes is the syntax around them. Every SRT timestamp of the form 00:00:01,000 becomes 00:00:01.000, because WebVTT writes a dot where SRT writes a comma, and the file gains the WEBVTT header line that players require at the top.
The cue numbers are kept. WebVTT allows an optional identifier before each cue and no player needs it, but keeping the numbers from the SRT file means you can read the two versions side by side and find the same cue in both.
Awkward input is fine: a byte-order mark, Windows line endings, an hour field with one digit, or a cue whose text is empty are all read without complaint, and the output is written back with the same tidy structure every time. Drop in one file or a whole season; the queue works through them in order, you can stop it part-way, and the results come down together as a single ZIP. Nothing is uploaded — the whole conversion runs in your browser.
Examples
A typical SRT file, converted to VTT
Input
1
00:00:01,000 --> 00:00:03,500
Hello there.
2
00:00:03,500 --> 00:00:06,000
<i>Whispering</i> now.
And a second line.
3
00:00:06,000 --> 00:00:09,250
<b>Bold</b> statement.
Output
WEBVTT
1
00:00:01.000 --> 00:00:03.500
Hello there.
2
00:00:03.500 --> 00:00:06.000
<i>Whispering</i> now.
And a second line.
3
00:00:06.000 --> 00:00:09.250
<b>Bold</b> statement.
Nothing is dropped here: compare the two sides line for line.
The same conversion on an awkward input
Input
1
0:00:01,00 --> 0:00:03,500
<B>Bold</B> and <I>italic</I>.
2
00:00:03,500 --> 00:00:06,000
3
00:00:08,000 --> 00:00:09,000
Last one.
Output
WEBVTT
1
00:00:01.000 --> 00:00:03.500
<b>Bold</b> and <i>italic</i>.
2
00:00:03.500 --> 00:00:06.000
3
00:00:08.000 --> 00:00:09.000
Last one.
This is the kind of damage real files have — mixed line endings, stray whitespace, fields left empty. Compare it with the tidy example above to see what the parser forgives.
Frequently asked questions
Do my SRT timings survive the move to WebVTT?
No. SRT's 00:00:01,250 and WebVTT's 00:00:01.250 are the same moment written two ways, so every start and end time is carried across to the millisecond. Only the character between the seconds and the milliseconds changes.
Are the cue numbers kept?
Yes, in the same places. WebVTT treats the number before a cue as a cue identifier, so 1, 2, 3 from the SRT file appear as 1, 2, 3 in the output. They are cosmetic, but they make the two files line up when you compare them.
What happens to italics, bold and other tags?
They are carried over as they are. SRT and WebVTT both use angle-bracket tags, so a run of italics in the input is a run of italics in the output. Nothing is rewritten or translated.
Why does the output start with WEBVTT?
Because that is the first line of the format. A file that looks like WebVTT in every other respect but does not begin with the word WEBVTT is rejected by players, which is the most common reason a hand-edited .vtt file will not load. It is added for you.
Is my SRT file sent anywhere?
No. The file is parsed and rewritten in the browser tab, so the only thing that crosses the network is the page itself. Nothing of the subtitles — text, timings or tags — goes into a request, and once the page has loaded it keeps working with the network switched off.