A WebVTT file, the caption format the web uses. It is plain text: the word WEBVTT on the first line, then cues made of a start time, an arrow, an end time and the text to show. Browsers read it through the HTML5 track element, and it can carry positioning and styling that the older SRT format cannot. Any text editor opens one.

Can I convert a .vtt back to .srt?

Yes. Drop the .vtt in and export the .srt. The header is removed, the millisecond separator becomes a comma, the cues are numbered in sequence, and anything SRT cannot represent is dropped rather than left in as text a player would show on screen. The result opens in VLC, in editing software and on a television.

Does it work on a file with no video?

Yes. The subtitle file is all the conversion needs, and the timeline and the cue list work from its timestamps alone. Adding the video is optional and only useful if you want to see the captions over the picture or check their timing against the waveform before you export.

SRT to VTT Converter, and VTT to SRT, Free

What changes between the two files

Both formats are plain text, both describe cues with a start time, an end time and some lines of text, and both are read by the same parser here. The differences are mostly cosmetic and entirely mechanical, which is why a conversion is a safe operation and not a lossy re-encode.

A .vtt begins with the word WEBVTT on its own line and an .srt does not. The milliseconds are separated with a period in WebVTT and a comma in SRT, so 00:00:01.500 in one is 00:00:01,500 in the other. SRT numbers each cue in sequence; WebVTT allows a cue identifier but does not require one, and the export here omits them because nothing reads them.

Everything else, the timing, the text, the line breaks, carries across unchanged. If your reason for converting is that a player rejected the file, the comma and the header are the two things it was objecting to.

What a VTT can carry that an SRT cannot, and what happens to it here

WebVTT was designed for the browser and carries more than timing. A cue can have positioning settings after its timestamps, placing it at the top of the frame or to one side. A voice tag can name who is speaking. STYLE blocks can carry CSS, NOTE blocks carry comments, and the text can hold italics and other inline markup.

SRT has no place for any of that, so a conversion to .srt necessarily drops it, and this tool drops it in both directions rather than pretending otherwise: positioning settings, voice tags, STYLE and NOTE blocks and inline markup are all removed on import, and what you export is timing and words. If you need positioning in a web player, keep the original .vtt and use this only for the .srt copy.

The one thing this does not drop is the line break inside a cue. A two-line caption stays two lines, because breaking a line is a reading decision somebody made on purpose and both formats preserve it.

Which one a player wants

A browser wants WebVTT. The HTML5 track element reads .vtt and nothing else, so a caption track on your own site, in a course platform built on a web player, or in any embedded player that uses the native track mechanism has to be a .vtt.

Nearly everything else wants SRT, or accepts both and defaults to SRT. Desktop players such as VLC, editing software such as Premiere and DaVinci Resolve, television sets reading from a USB stick, and the upload forms of most video platforms all take an .srt. The large platforms accept both, and for them the choice does not matter.

When a platform offers both and you have styling to preserve, send the .vtt. When you are sending a file to someone whose player you do not know, send the .srt, because the player that cannot read an .srt is rarer than the one that cannot read a .vtt.

Done in the browser, and what you can do before exporting

The file is read in the tab, parsed in the tab and written back out in the tab. Nothing is sent anywhere, there is no size limit, and you can disconnect from the network before dropping the file if you want to see that for yourself.

Since the cues are in the editor anyway, you can do more than convert. Each line is checked against the reading-speed and line-length conventions, at most 42 characters a line and 17 characters a second, and flagged if it fails. You can fix a typo, merge two cues, shift the whole track, or add the video and watch the captions render over it before you export.

Export produces an .srt and a .vtt from the same cues, so the two files you leave with are guaranteed to agree with each other, which is not something you can say for a pair of files that have been edited separately.

Questions

What is a .vtt file?: A WebVTT file, the caption format the web uses. It is plain text: the word WEBVTT on the first line, then cues made of a start time, an arrow, an end time and the text to show. Browsers read it through the HTML5 track element, and it can carry positioning and styling that the older SRT format cannot. Any text editor opens one.
Will the conversion lose anything?: From .srt to .vtt, nothing: everything an SRT can hold, a VTT can hold too. From .vtt to .srt, yes, and the losses are listed above: positioning settings, voice tags, STYLE and NOTE blocks and inline markup, none of which SRT has anywhere to put. The timing, the words and the line breaks survive in both directions.
Can I convert a .vtt back to .srt?: Yes. Drop the .vtt in and export the .srt. The header is removed, the millisecond separator becomes a comma, the cues are numbered in sequence, and anything SRT cannot represent is dropped rather than left in as text a player would show on screen. The result opens in VLC, in editing software and on a television.
Does it work on a file with no video?: Yes. The subtitle file is all the conversion needs, and the timeline and the cue list work from its timestamps alone. Adding the video is optional and only useful if you want to see the captions over the picture or check their timing against the waveform before you export.