VTT to SRT
Or paste subtitle text
What this conversion changes
2 things are dropped or need a decision
- Styling
all styling (bold, italic, colour, outline, shadow)
- Format-specific content
content the source format keeps outside its cues (non-cue blocks, header text, per-cue settings, commented-out events) — the target format has no place for it
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.
This page converts WebVTT to SRT. Drop a file in — or paste the text — and you get the SRT version back. The conversion runs entirely in your browser: nothing is uploaded, no account is needed, and the page keeps working with the network switched off once it has loaded.
The two formats hold the same subtitles, so the text, the line breaks and the timings come across to the millisecond. What changes is the syntax: every VTT timestamp of the form 00:00:01.000 becomes 00:00:01,000, because SRT writes a comma where WebVTT writes a dot, and the WEBVTT header line goes away, because SRT files have no header.
What does not come across is everything WebVTT stores outside its cues. The header line can carry a comment — WEBVTT - exported from some platform — the file can contain NOTE, STYLE and REGION blocks, and a STYLE block may hold the whole document's layout rules. A timestamp can also be followed by settings such as align:start or position:10%. SRT's syntax has no slot for any of it, so it is dropped rather than reinterpreted, and the cue identifiers become plain sequential numbers, because SRT's counter has to be a number. The report above lists what has nowhere to go, and fills in how much of it your particular file has as soon as you load it.
Awkward input is fine: a missing header, Windows line endings, a stray line before a timestamp or a byte-order mark 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.
Examples
A typical VTT file, converted to SRT
Input
WEBVTT
intro
00:00:01.000 --> 00:00:04.000
Hello there.
00:00:04.500 --> 00:00:08.000 align:start position:10%
Second line with <i>italics</i>.
Output
1
00:00:01,000 --> 00:00:04,000
Hello there.
2
00:00:04,500 --> 00:00:08,000
Second line with <i>italics</i>.
Dropped in this output: styling and format-specific content. Everything else matches line for line.
The same conversion on an awkward input
Input
a stray comment line
cue-id-1
00:00:01.000 --> 00:00:02.000
No header, two lines before the timecode.
Output
1
00:00:01,000 --> 00:00:02,000
No header, two lines before the timecode.
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
Are the WebVTT timings changed on the way to SRT?
No. WebVTT's 00:00:01.250 and SRT'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.
What happens to the WEBVTT header and to NOTE, STYLE and REGION blocks?
They are dropped. SRT has no header line and no block syntax, so there is nowhere to put them. That matters most for STYLE, which often holds the document's layout rules rather than a passing comment: if your player relied on it, that styling has to move somewhere else.
What happens to settings after a timestamp, like align:start or position:10%?
They are dropped too. SRT cannot place a cue anywhere on screen. If placement matters in the output, convert to ASS instead: there the positioning lives in override codes such as \an7 and \pos, and it travels with the text.
Do my cue identifiers survive into SRT?
No. WebVTT allows free-form identifiers such as intro or sign-1 before a cue, and this converter reads them, but SRT's counter is a number by convention, so the output is renumbered 1, 2, 3. Strict SRT parsers reject a file whose counter is not numeric, which is why the identifiers are not carried over as they are.
Can I use this on a confidential file?
The file never leaves your machine. Parsing and writing happen in the browser, no request carries your subtitles anywhere, and the page also works with the network switched off once it has loaded.