Turn WebVTT (.vtt) subtitle files into SubRip (.srt) in a few clicks—fast, simple, and works in any modern browser.
.vtt file or click "Add Files" to browse. The file is parsed in your browser. Batch conversion is supported, so you can drop a full season of WebVTT cues at once.WEBVTT header and any NOTE, STYLE, or REGION blocks, rewrites timestamps from dot-millisecond (00:01:23.456) to comma-millisecond (00:01:23,456), and inserts sequential numeric cue IDs that SRT requires.line:, position:, align:, or vertical:, those are dropped during conversion — SRT has no equivalent syntax. Inline styling tags such as <b>, <i>, <u>, and <font color> are preserved verbatim because most modern players (VLC, MPV, mpv-android) honor them inside SRT too.WebVTT was designed by the W3C for the HTML5 <track> element — it lives natively in browser-based players. SubRip (SRT), invented in 2000 for the SubRip ripping tool, predates HTML5 by a decade and became the universal interchange format for desktop video editors, set-top boxes, and upload pipelines. When a platform rejects your .vtt or your editor garbles it, swapping the comma/period and dropping the header is almost always the fix.
movie.srt next to movie.mkv. Drop a .vtt in the same folder and many of these players silently ignore it.mov_text muxer treat SRT as the canonical text-subtitle input. Embedding subtitles into an MP4 or MKV almost always starts from SRT.| Property | VTT (WebVTT) | SRT (SubRip) |
|---|---|---|
| Standardised by | W3C (webvtt1 Candidate Recommendation Draft) |
de-facto standard from SubRip tool |
| File header | Required: WEBVTT on line 1 |
No header |
| Timestamp separator | Dot: 00:01:23.456 |
Comma: 00:01:23,456 |
| Cue numbering | Optional | Required, sequential |
| Inline styling tags | <b> <i> <u> <c> <ruby> <v> plus CSS classes |
<b> <i> <u> <font color> (player-dependent) |
| Positioning | line: position: align: vertical: size: |
None |
| STYLE / REGION blocks | Yes — embedded CSS and named regions | Not supported |
| NOTE comments | Yes | Not supported |
HTML5 <track> element |
Native | Not supported by browsers without conversion |
| MIME type | text/vtt |
application/x-subrip (informal) |
| Typical use | Web players, MDN-style HTML5 video | Editors, OTT, sidecar files, social uploads |
| VTT feature | Behavior in SRT output |
|---|---|
WEBVTT header line |
Removed |
NOTE comment blocks |
Removed |
STYLE blocks (embedded CSS) |
Removed |
REGION blocks |
Removed |
| Cue identifier strings (non-numeric) | Replaced with sequential numbers (1, 2, 3…) |
Cue settings (line position align vertical size) |
Stripped from the timestamp line |
<c.classname> class spans |
Class removed; inner text kept |
<v Speaker> voice tags |
Most players don't render them in SRT — text remains, speaker label may show as raw tag |
<b> <i> <u> tags |
Preserved (widely supported in SRT players) |
& < > entities |
Preserved |
| UTF-8 encoding | Preserved |
Adobe Premiere Pro and Final Cut Pro both can read VTT in recent versions, but the implementations are stricter than their SRT parsers. A VTT with cue settings, regions, or non-numeric identifiers may import as empty captions or throw "unsupported format." SRT's simpler grammar — header-less, comma-millisecond, numeric IDs — round-trips through every NLE that has shipped in the last 20 years. If you're hitting "no captions detected" errors, converting to SRT almost always fixes it.
Inline <b>, <i>, <u>, and <font color="#ff0000"> tags are passed through unchanged. VLC, MPV, Plex, Jellyfin, and most modern players render them. What you will lose: VTT-only constructs such as <c.classname> (the class is dropped, text kept), <ruby> annotations, named voice tags <v Speaker>, and any styling that lived in a separate STYLE block. SRT has no concept of CSS — there's nowhere to put it.
YouTube accepts both along with SBV, TTML, DFXP, SCC, and several broadcast formats. SRT is the most common choice for human-authored captions because it works identically when you cross-post the same file to Vimeo, Facebook, Twitter/X, and LinkedIn. For broadcast-style closed captions with positioning, YouTube actually prefers SCC (Scenarist) over both SRT and VTT.
They aren't — the timestamps are byte-for-byte identical, only the separator changed (. to ,). Some text editors with autocorrect or smart-quotes settings can silently mangle the comma. Open the converted file in a code-aware editor (VS Code, Sublime, Notepad++) rather than Word or TextEdit-with-RTF to confirm.
Yes. The conversion is a streaming text transform — VTT parses into cue objects, then serializes to SRT — and runs entirely in a Web Worker so the main thread stays responsive. Even files with 10,000+ cues from a multi-hour lecture or audiobook convert in well under a second on a typical laptop.
A missing or malformed WEBVTT header is technically a parser error per the W3C spec, but real-world VTTs in the wild sometimes omit it (export bugs, hand-edited files). The converter is lenient: if the cue structure is recognisable — timestamps with --> arrows separated by blank lines — it will parse anyway and emit valid SRT.
For end users adding subtitles to a personal copy of a video, yes — any SRT player will load it. For Netflix partner deliveries, no platform-converted SRT is acceptable: Netflix requires TTML1 (.xml or .ttml) for all subtitle and SDH deliveries from content partners, with strict frame-rate, positioning, and timed-text profile rules. SRT is fine for personal viewing, fan subs, and almost every other platform.
Yes, that's a separate one-click conversion. It adds the WEBVTT header, flips commas back to periods, and strips the cue numbers if you want a minimal file. Useful when you need to embed captions into an HTML5 <track> element on your own website.
UTF-8, no BOM. This matches what every modern player, editor, and platform expects. If a legacy Windows player (older versions of PotPlayer, Light Alloy) shows mojibake on accented characters, the workaround is to resave the file as UTF-8-with-BOM or Windows-1252 in a text editor — but in 2026 this is rare.