VTT to SRT Converter (Free, Client-Side)
Convert .vtt to .srt — or the other way around — entirely in your browser. Nothing leaves your device. Honest conversion report shows exactly what got stripped.
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 the WEBVTT header, timecode separator swap (period ↔ comma), cue identifier renumbering, and strips WebVTT-only features (inline styling, cue positioning, NOTE and STYLE blocks) that SRT can't represent.
or drag & drop, or paste text below
What just happened — the conversion in one paragraph
Four mechanical changes turn a WebVTT file into a valid SRT file. First, the WEBVTT header line — plus any NOTE, STYLE, and REGION blocks — get removed because SRT has no header concept. Second, every timecode's millisecond separator flips from a period (00:00:03.500) to a comma (00:00:03,500). Third, VTT cue identifiers (the optional label line above each timecode) are replaced with sequential numbers starting at 1, because SRT requires numbered cues. Fourth, inline styling like <c.className>, <v Speaker>, and cue positioning settings (line:0 position:50%) get stripped because SRT has no equivalent syntax. Text, timing precision, and cue order stay identical.
SRT → VTT is the reverse: prepend the WEBVTT header, swap commas back to periods in timecodes, drop the sequence numbers (they're optional in VTT). The rest — text and timing — is a straight passthrough.
VTT vs SRT — quick difference
Both are plain-text subtitle formats. Below is what actually differs at the file level.
| Field | VTT (WebVTT) | SRT (SubRip) |
|---|---|---|
| Timecode separator | Period — 00:00:03.500 | Comma — 00:00:03,500 |
| File header | Required WEBVTT line at top | None — starts with cue #1 |
| Cue identifier | Optional label above timecode | Sequential number (1, 2, 3…) |
| Inline styling | <c.class>, <v Speaker>, <i>, <b>, <ruby> | Text only (some players honor <i>, <b>) |
| Positioning | line:, position:, align:, size: | Not supported |
| Primary use | HTML5 <track>, HLS streaming | YouTube, Premiere, DaVinci, CapCut |
For a deeper dive on the SubRip format specifically, see What is an SRT file? — covers structure, encoding, and player compatibility in detail.
When to convert VTT → SRT
Convert to SRT whenever the destination is a video editor or a caption upload workflow that isn't a web browser. Concrete cases:
- YouTube Studio caption upload. YouTube accepts both, but SRT is the format YouTube's docs and every tutorial reference — safer and easier to troubleshoot.
- Adobe Premiere Pro, Final Cut Pro, DaVinci Resolve, Avid Media Composer. All parse SRT natively via File → Import Captions. VTT support varies by version and is buggier in older releases.
- CapCut, InShot, VN, and other mobile editors. SRT is the universal import format. Some don't accept VTT at all.
- Vimeo, Wistia, and legacy broadcast tools. SRT is the safe default when platform docs don't explicitly list VTT.
- VLC, MPC-HC, PotPlayer (desktop players). Both work, but SRT sidecar files are the de facto standard next to a video file.
When to convert SRT → VTT
Convert to VTT when the destination is a web browser rendering an HTML5 <video> element. Concrete cases:
- HTML5 <track> embedding. Browsers only parse WebVTT for the
<track kind="captions" src="...">element. An .srt attached to a track tag will silently fail. - HLS and DASH streaming. Adaptive-bitrate streaming manifests reference WebVTT sidecars for closed captions. If you have SRT masters, convert before packaging.
- Video.js, Plyr, and other JS video players. Most require VTT — some support SRT via plugins, but VTT is the safe default.
- Self-hosted educational videos with styled captions. Only VTT supports CSS-styleable cue classes, positioning, and speaker voice tags.
What gets lost in conversion
Only VTT → SRT loses information (SRT → VTT is lossless because SRT is the simpler format). Here's the full list of what the WebVTT spec supports that SRT cannot represent, and what this tool does with each:
- Inline styling tags.
<c.className>,<v Speaker>,<i>,<b>,<u>,<ruby>,<rt>— all stripped. The plain text between the tags is preserved. - Cue positioning settings.
line:,position:,align:,size:,vertical:— dropped from the timecode line. - File-level metadata. The
WEBVTTheader,NOTEblocks (comments),STYLEblocks (embedded CSS), andREGIONdefinitions all get removed. - Cue identifiers. Optional labels above the timecode in VTT (e.g.
intro-01) are replaced with sequential numbers, which SRT requires. - Chapter cues. WebVTT chapter tracks (used for jump-to-section navigation in HTML5 video) have no SRT equivalent — the tool converts them to plain cues, which most editors will treat as extra subtitles.
What's preserved: cue text, cue order, timing precision to the millisecond, blank lines between cues, and UTF-8 encoding. The conversion report above the converter tells you exactly what was stripped from your specific file.
Common errors and fixes
Mojibake — accented characters look like é or ’
Symptom: You uploaded a Windows-1252 or ISO-8859-1 file. UTF-8 characters got misread.
Fix: Re-save the file as UTF-8 (without BOM). 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 one runs into the next.
Fix: SRT requires a single blank line between every cue. If your source VTT was hand-edited without blank lines, the parser treats it as one cue block. Fix the source, then convert.
Player rejects the .srt as broken
Symptom: VLC, YouTube Studio, or your editor won't load the file.
Fix: Check timecode format — SRT uses HH:MM:SS,mmm (comma, three-digit milliseconds). If your file has HH:MM:SS.mmm (period) it's still in VTT format. Re-download from this tool.
UTF-8 BOM breaks the first cue
Symptom: Cue #1 shows as 1 with an invisible prefix, or the player skips it.
Fix: Save without BOM. This tool exports without BOM by default; the issue is usually a source file exported by Excel or older Notepad.
Don't have a subtitle file yet?
This converter only transforms an existing .vtt or .srt file. If you have a video or audio file and no subtitles, you need transcription first, then conversion. VexaScribe generates both formats directly from source media using Whisper Large-v3 — word-level timestamps, 99 languages, and you pick the export format at the end. No conversion step needed.
Frequently Asked Questions
What actually changes when I convert VTT to SRT?
Four things. (1) The WEBVTT header line and any header metadata (NOTE, STYLE, REGION blocks) are removed — SRT doesn't have them. (2) Timecodes change separator: 00:00:03.500 (VTT uses a period before milliseconds) becomes 00:00:03,500 (SRT uses a comma). (3) Cue identifiers (optional labels above the timecode line in VTT) are replaced with sequential numbers starting at 1 — SRT requires numbered cues. (4) Inline styling and positioning are stripped: WebVTT <c.className>, <v Speaker>, <i>, <b>, <ruby>, cue positioning (line:0 position:50%) all disappear because SRT has no equivalent syntax. Text content, timing accuracy, and speaker order are preserved.
Does the file leave my browser?
No. This converter runs entirely in your browser — the .vtt or .srt 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?
WebVTT-specific features that SRT can't represent. Styling: <c.class>, <v Speaker>, <i>, <b>, <u>, <ruby>, <rt> tags all get stripped. Positioning: cue settings like line:0, position:50%, align:center are dropped. Metadata: WEBVTT header + NOTE blocks + STYLE blocks + REGION definitions all removed. Cue identifiers (the optional label line above a timecode) are replaced with sequential numbers. The conversion report on this page tells you exactly what was stripped from your file. Text content, timing precision, and cue order are all preserved.
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>), keep VTT. If your target is a video editor or upload to YouTube Studio, convert to SRT.
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 and want to attach it to a <video> element via <track>, run it through the SRT → VTT direction on this converter first.
What about SSA / ASS / TTML formats?
This converter handles the two most common subtitle formats: SRT and VTT. For SSA/ASS (Advanced SubStation Alpha — anime and karaoke), the conversion path is more complex because ASS has extensive styling that 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 the SRT ↔ VTT conversion because they represent 90%+ of creator-workflow subtitle conversions.
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). YouTube Studio, most video editors, and this converter all expect UTF-8. If you paste text with mangled characters into this converter's input, the output will also have mangled characters — fix the encoding at the source first.