SRT to VTT converter for video captions.

WebVTT is the caption format used by HTML video text tracks. If a web player, documentation site, learning platform, or product page asks for a .vtt file, convert the SRT file before uploading it.

The important difference is syntax. SRT commonly uses comma-based milliseconds, while WebVTT uses periods and starts with a WEBVTT header. This converter handles that formatting change and keeps the caption text visible for review.

To create a caption file from a video instead of converting an existing subtitle file, start with the AutoCaption caption generator. If you are starting with a WebVTT file and need an SRT file instead, use the VTT to SRT converter. If the caption text needs translation, use the video subtitle translator. If the cues are out of sync with the video, correct that first with the subtitle timing shifter, and to pull the words out as a readable transcript use the SRT to text converter. For format choice guidance, read the SRT vs VTT guide.

The visible differences are easy to describe. WebVTT wants a WEBVTT header, and it separates seconds from milliseconds with a full stop where SRT uses a comma. Both are the kind of thing you could fix by hand.

The difference that breaks files is invisible, and it is inside the caption text rather than around it. SRT has no escaping rules at all: an ampersand is an ampersand and an angle bracket is an angle bracket. WebVTT reserves both, because < opens a cue span and & opens a character reference.

So a line that is perfectly valid in SRT can be invalid in WebVTT, and it fails quietly rather than loudly. Nothing reports an error. A cue reading "5 < 10 and then some" can simply lose everything after the bracket, because a parser reads it as the start of a tag that never closes.

This converter escapes on the way in:

SRT in:      Fish & chips, 5 < 10
WebVTT out:  Fish &amp; chips, 5 &lt; 10

Italic, bold and underline pass through untouched, because they are valid in both formats and are the only markup SRT players broadly agree on. A <font> tag is common in SRT files and is not WebVTT at all, so its tags are dropped and the words inside are kept, which beats showing a viewer raw markup. Anything else in angle brackets is escaped rather than deleted, so it displays as the author typed it instead of taking a sentence with it.

Existing entities are left alone rather than escaped twice, and the conversion back to SRT unescapes, so a round trip returns the characters you started with. If you are trying to work out which of the two faults you are looking at, the guide to subtitle character problems separates a markup fault from an encoding one.