SRT to VTT Subtitle Converter

Convert SRT subtitle files to WebVTT format for HTML5 video with timing preservation.

Tested tool guide Tested browser tools Checked August 16, 2026

What SRT to VTT Subtitle Converter does, with a checked example

SRT and WebVTT are both plain-text caption formats built from numbered cues - a time range and one or more lines of text each - but two mechanical details separate them: SRT writes milliseconds after a comma, WebVTT after a period, and a WebVTT file must begin with a WEBVTT header line that SRT has no equivalent of. This tool reads pasted SRT text, rewrites every timestamp, adds the header, and returns WebVTT ready for the <track> element of HTML5 video. Most users are surprised that cue numbers, text, and timing all survive untouched.

Worked example

A concrete input and expected output from the current implementation.

Input

1
00:00:02,500 --> 00:00:05,000
Hello, world!

2
00:00:07,750 --> 00:00:10,000
Second cue

Expected output

WEBVTT

1
00:00:02.500 --> 00:00:05.000
Hello, world!

2
00:00:07.750 --> 00:00:10.000
Second cue

SRT writes milliseconds after a comma and has no file header; WebVTT requires a WEBVTT line at the top and a period before milliseconds. Everything else - cue numbers, timings, and text - maps one to one, so the header and the two separators are the only changes.

How the result is produced

Timestamp rewrite

Each timing line such as 00:00:02,500 --> 00:00:05,000 is rewritten to 00:00:02.500 --> 00:00:05.000: the comma after the seconds becomes a period, and both times otherwise pass through verbatim. WebVTT also permits omitting the hours field for cues under an hour (MM:SS.mmm), but the full HH:MM:SS.mmm form is valid in both formats, so converters generally keep it.

Structure assembly

The pasted text is split into blank-line-separated blocks and any byte-order mark is discarded. The tool writes WEBVTT as the first line, leaves a blank line, then emits each block in order with its cue number kept as a WebVTT identifier - an optional label the format does not require. Text and inline markup such as pass through unchanged, so only the header and the timestamp separators differ from the input.

Good uses

Adding captions to a self-hosted HTML5 video: the <track> element only accepts WebVTT, so an SRT caption file must be converted before the player will render it.
Migrating a folder of SRT files into a single canonical caption format for an archival or delivery pipeline that standardizes on WebVTT.
Sending subtitles to a colleague or a caption-editing platform whose importer accepts only .vtt, preserving the exact timings instead of retyping them.

Limits and checks

Verify the separator: an output line that still reads ,000 after the seconds is not valid WebVTT and the player will reject the cue. The comma-to-period change is the one transformation worth checking visually.
Positioning does not survive: SRT variants that embed position extensions after the arrow (X1:, X2:) and WebVTT-only settings such as line: or align: have no counterpart in the other format, so cues that were deliberately placed off-center end up at default positions.
Unsupported markup: WebVTT parses only a small tag set (<c>, , , , <v>, <ruby>, <rt>). SRT cues styled with other tags, most commonly , lose that styling when the player renders the cue.

Common questions

Why does the output still show the same numbers as my SRT - did anything get converted?

It did, and the conversion is intentionally minimal. The mandatory changes are the WEBVTT header line and the comma-to-period separators in the timestamps; cue numbers, text, and timing map one-to-one because the two formats share the same cue structure. Diff the files and you should see only those two changes - anything more is a converter adding or removing content.

Will a <video> element play this directly?

Yes, but only through a <track> element - browsers do not apply caption files to a video just because one is hosted nearby. Point <track src="subtitles.vtt" kind="subtitles" srclang="en" label="English"> at the converted file. One server caveat: the .vtt response should carry the text/vtt content type, because strict browsers ignore track resources served with the wrong MIME type.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.