SRT to VTT Converter (Free, Client-Side)
Convert .srt to .vtt — or the other way around — entirely in your browser. Nothing leaves your device.
Drop a subtitle file (or paste text), pick a direction, download the converted file. The tool runs 100% in your browser using JavaScript — no upload, no server, no account. Handles WEBVTT header addition, timecode separator swap (comma → period), and UTF-8 encoding normalization. SRT → VTT is essentially lossless because SRT is a subset of what WebVTT can express.
or drag & drop, or paste text below
How to convert SRT to VTT (3 steps)
- 1
Drop the .srt file or paste text
The tool auto-detects direction (SRT input → VTT output, and vice versa). Files stay in your browser.
- 2
Click Convert
JavaScript in the browser runs the conversion — parses cues, swaps separators, adds the WEBVTT header, and normalizes to UTF-8. No server round-trip.
- 3
Download the .vtt file
The output is ready for HTML5 <track>, HLS streaming, or any browser video player. Attach it to your <video> element and captions display.
What changes in SRT → VTT conversion
SRT → VTT is essentially lossless because SRT is a subset of what WebVTT can express. Here's what happens under the hood.
WEBVTT header added at top of file
WebVTT specification requires this line as the first line. Our converter adds it automatically.
Timecode separator: comma → period
SRT timecodes use a comma before the millisecond digits (00:00:03,500). VTT uses a period (00:00:03.500). Every timecode in the file is converted.
Encoding normalized to UTF-8
WebVTT requires UTF-8. If your source SRT was UTF-8 already, nothing changes visibly. If it was Windows-1252 or ISO-8859-1, we re-encode so accented characters render correctly.
Cue identifiers preserved
SRT uses sequential numbers (1, 2, 3…) above each cue's timecode. VTT allows these but doesn't require them. Our converter keeps them for maximum compatibility with players that expect them.
Text and timing unchanged
The dialogue text and timecodes are copied over identically. Only the format wrapper changes.
SRT vs VTT — technical differences
Both are timed-text subtitle formats. VTT extends SRT with styling, positioning, and metadata for HTML5 web video. SRT stays intentionally simple for maximum player compatibility.
| Attribute | SRT (SubRip) | VTT (WebVTT) |
|---|---|---|
| Timecode separator | Comma — 00:00:03,500 | Period — 00:00:03.500 |
| File header | None — starts with cue #1 | Required WEBVTT line at top |
| Cue identifier | Sequential number (1, 2, 3…) | Optional label above timecode |
| Encoding | UTF-8 assumed; not required by spec | UTF-8 required by W3C specification |
| Inline styling | Text only (some players honor <i>, <b>) | <c.class>, <v Speaker>, <i>, <b>, <ruby> |
| Positioning | Not supported | line:, position:, align:, size: |
| Primary use | YouTube, Premiere, DaVinci, CapCut, VLC | HTML5 <track>, HLS streaming, browser players |
When to convert SRT → VTT (and when not to)
Convert SRT → VTT when:
- Attaching captions to an HTML5
<video>element via a<track>tag (browsers require VTT). - Delivering captions via HLS or DASH streaming — WebVTT is the standard for adaptive streaming.
- Serving a video on your own website with a browser-native player.
- Building a WebVTT-styled caption experience (font styling, positioning).
Stay with SRT when:
- Uploading captions to YouTube Studio (YouTube accepts both, SRT is more common).
- Importing into a video editor (Premiere, DaVinci Resolve, Final Cut Pro, CapCut) — SRT is universally accepted.
- Attaching to a movie file for VLC or a media-player workflow.
- Sharing subtitles with a subtitle-editing tool (Subtitle Edit, Aegisub).
Common conversion errors and fixes
Player rejects the .vtt as broken
Symptom: The HTML5 <video> element doesn't show captions, or the browser DevTools shows a WebVTT parse error.
Fix: Verify the WEBVTT header is the very first line of the file (no blank line, no BOM before it). Our converter outputs this correctly; issues usually come from further hand-editing after conversion. Also check that timecodes use periods, not commas.
UTF-8 BOM breaks the WEBVTT header
Symptom: Cue #1 doesn't render, or the player says 'file must start with WEBVTT'.
Fix: The invisible BOM (\uFEFF) prefix before WEBVTT is a common issue with files saved by Excel or older Notepad. Save without BOM. Our converter exports without BOM by default; this only happens if you edit the output file afterward.
Accented characters look like é or ’
Symptom: Your source SRT was Windows-1252 or ISO-8859-1 encoded.
Fix: Re-save the source SRT as UTF-8 before conversion. In VS Code: bottom-right encoding label → Save with Encoding → UTF-8. Notepad++: Encoding menu → Convert to UTF-8. Then re-run the converter.
Cues merge on screen after conversion
Symptom: Two subtitles show at once, or the caption sequence is misaligned.
Fix: SRT requires a single blank line between every cue. If the source SRT was hand-edited without blank lines, the parser reads it as one giant cue block. Fix the source, then re-convert.
Privacy — client-side only
The converter widget on this page runs entirely in your browser using JavaScript. When you drop an .srt file, the browser reads it locally, parses the cues, adds the WEBVTT header, swaps timecode separators, and generates the .vtt output — all without ever sending the file to our servers.
You can verify this yourself: open browser DevTools → Network tab → run a conversion. You'll see zero requests for your subtitle file. That matters when the subtitle file contains sensitive content (internal training, customer support recordings, unreleased media).
For AI transcription that requires server-side processing (audio → text with Whisper Large-v3), our uploaded-file workflow uses EU hosting (AWS eu-west-2) with no training on customer data. See our privacy policy for details.
Frequently asked questions
What actually changes when I convert SRT to VTT?
Four things. (1) A WEBVTT header line is added at the top of the file — WebVTT requires this; SRT doesn't have it. (2) Timecodes change separator: 00:00:03,500 (SRT uses a comma before milliseconds) becomes 00:00:03.500 (VTT uses a period). (3) Cue identifiers (the numeric labels above each timecode line in SRT) are optional in VTT — most VTT-consuming players accept them, but strict WebVTT tolerates their absence. Our converter keeps them for maximum compatibility. (4) Encoding is normalized to UTF-8 (WebVTT specification requires UTF-8). Text content, timing accuracy, and cue order are preserved.
Does the file leave my browser?
No. This converter runs entirely in your browser — the .srt or .vtt file you upload is read and processed locally with JavaScript. No upload to any server, no request to any API. You can verify by opening browser DevTools → Network tab — you won't see a request for your subtitle file. This matters when the subtitle file contains sensitive content (customer support recordings, internal training, unreleased media).
What gets lost in the conversion?
Almost nothing — SRT is a subset of what WebVTT can express, so SRT → VTT is essentially lossless. What changes: timecode separator, header addition, encoding normalization. What's preserved: text, timing, cue order, cue numbering. VTT can express things SRT can't (positioning, styling, `<c>` classes, `<v>` speaker tags), but converting FROM SRT means starting from a simpler format — you're not losing anything because SRT didn't have those features in the first place.
Why do HTML5 web players want VTT instead of SRT?
The HTML5 <track> element specifically requires WebVTT format for embedded captions and subtitles. The W3C standardized WebVTT (Web Video Text Tracks) around 2010 to support CSS-like styling, cue positioning, and metadata inline with captions — features that make sense in a browser rendering environment. Browsers won't parse an .srt file as an HTML5 <track>. If you have an SRT file (from a video editor export, YouTube download, or transcription tool) and want to attach it to a <video> element, running through SRT → VTT is the required first step.
Why do YouTube and video editors want SRT instead of VTT?
SRT (SubRip) is older (early 2000s) and simpler — no styling, no metadata, no positioning options. That simplicity made it universal: virtually every video editor (Premiere, DaVinci Resolve, Final Cut Pro, CapCut, Avid), every subtitle player (VLC, MPC), and YouTube's caption upload workflow parse SRT natively. WebVTT (W3C-standardized 2010) is newer and richer — designed for the HTML5 <track> element with styling and positioning — but that richness isn't supported by most non-web platforms. If your target is web (HTML5 <video>), convert to VTT. If your target is a video editor or YouTube Studio upload, keep the SRT.
How do I know if my file is UTF-8?
Open it in a text editor. If accented characters (é, ñ, ü) or non-Latin scripts (Japanese, Arabic, Chinese) render correctly, it's UTF-8. If they show as garbage characters (é, ñ) or empty boxes, the file was saved in a different encoding (Windows-1252, ANSI, ISO-8859-1). Re-save the file as UTF-8 in VS Code, Sublime, or Notepad++ (via Encoding menu). WebVTT specifically requires UTF-8; SRT doesn't formally require it but most modern tools assume UTF-8. Our converter normalizes to UTF-8 in the output.
Does the converter handle SSA / ASS / TTML formats?
No — this converter handles SRT and VTT, the two most common creator-workflow subtitle formats. For SSA/ASS (Advanced SubStation Alpha — used for anime and karaoke with extensive styling), the conversion path is more complex because ASS has features neither SRT nor VTT can represent — use Subtitle Edit or Aegisub for that. For TTML/IMSC1.1 (broadcast, Netflix delivery), use a professional subtitle tool that handles XML-based formats. This converter is intentionally focused on SRT ↔ VTT because they represent 90%+ of creator-workflow subtitle conversions.