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 — nothing leaves your device. 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.