How to use
- Drop your file(s) into the box above — or click it to browse.
- Conversion starts immediately — no settings needed.
- Click Download on each finished file — or Download all (.zip) for a batch. Nothing was uploaded at any point.
Why players demand VTT instead of SRT
SRT (SubRip) is the lingua franca of downloaded subtitles, but the web standard is WebVTT: the HTML5 <track> element accepts only VTT, and so do Video.js, Plyr, JW Player, HLS players, and most embeddable web video stacks. If you hand them an SRT they silently show no captions — the single most common reason "subtitles don't work" on a self-hosted video.
The formats are close cousins, which is why conversion is lossless: VTT adds a WEBVTT header, switches the millisecond separator from a comma (00:00:01,000) to a dot (00:00:01.000), and drops the cue numbers. Your text, line breaks, and <i>/<b> styling all survive intact.
| SRT | WebVTT | |
|---|---|---|
| Standardized by | De-facto (SubRip, 2000s) | W3C (for HTML5 video) |
| Timestamp | 00:01:02,500 (comma) | 00:01:02.500 (dot) |
| Header | None | WEBVTT line required |
| HTML5 <track> | Rejected | Required format |
| Styling | <i> <b> <u> tags | Same tags + optional CSS cues |
| Positioning | No standard | Cue settings (line/position) |
Encoding is half the battle
Browsers require VTT to be UTF-8. A large share of SRT files downloaded from subtitle sites are actually Windows-1252, UTF-16, or EUC-KR — and feeding those to a <track> produces mojibake or nothing at all. This converter sniffs the real encoding first and always emits clean UTF-8, which fixes the second most common "captions are garbled" bug for free.
When NOT to convert SRT to VTT
- Desktop players — VLC, mpv, PotPlayer and IINA all read SRT natively; converting gains nothing there.
- YouTube uploads — YouTube accepts SRT directly; no conversion needed.
- Burned-in subtitle workflows — tools like HandBrake take SRT; convert only when a web player is the destination.