Subtitle Formats
How to Convert SRT to VTT Without Uploading Your Files
To convert SRT to VTT, you only need two changes: add the line 'WEBVTT' (followed by a blank line) at the very top of the file, and replace the comma in every timestamp with a period, so 00:01:42,300 --> 00:01:45,100 becomes 00:01:42.300 --> 00:01:45.100. That's the entire structural difference for a basic file. You can make those changes in a plain text editor, with a single ffmpeg command, or with a client-side browser tool, and none of these methods require uploading your subtitles anywhere.
Quick version: WEBVTT header on line one, timestamp commas become periods, save as .vtt with UTF-8 encoding. Timing and text stay identical.
What's actually different between SRT and VTT?
SRT (SubRip) is the plain-text veteran: numbered cues, comma-separated milliseconds, no header, no styling beyond a few HTML-ish tags. WebVTT was designed later specifically for the web, as the caption format for the HTML5 <track> element. Structurally they are near-twins, which is why conversion is so mechanical. The real differences:
- Header: a VTT file must begin with the text 'WEBVTT' on its own line. SRT has no header at all.
- Milliseconds separator: SRT writes 00:01:42,300 (comma); VTT writes 00:01:42.300 (period). This is the change people most often miss.
- Cue numbers: required in SRT, optional in VTT. Converters usually keep them, and that's fine.
- Styling: VTT supports CSS styling via ::cue and class tags, plus per-cue position and alignment settings. SRT has none of that.
- Comments: VTT allows NOTE blocks that players ignore; SRT doesn't.
- Encoding: VTT must be UTF-8. SRT files in the wild come in all sorts of legacy encodings, which is a common source of garbled characters after conversion.
When do I actually need VTT instead of SRT?
The dividing line is the web. If your video plays in a native HTML5 player on a website, the captions track must be WebVTT; browsers don't accept SRT in the <track> element. Video platforms and players built on web tech (many online course platforms, embedded players, some CMSes) inherit that requirement. Everywhere else, SRT still rules: VLC, Plex, Kodi, most TVs, and YouTube all take SRT directly. So the typical reason you're here: you have a working SRT and a web page that demands a .vtt.
How do I convert SRT to VTT without uploading anything?
Upload-based converter sites work, but they mean handing your transcript to a server you don't control. For client work, unreleased footage, or anything under NDA, use a method that keeps the file on your machine. Three options, simplest first.
Method 1: any text editor (no tools needed)
- Open the .srt file in a plain-text editor (VS Code, Notepad, TextEdit in plain-text mode).
- Add 'WEBVTT' as the first line, followed by one empty line.
- Replace timestamp commas with periods. Do it safely with find-and-replace on the pattern ',' only within timestamp lines; in an editor with regex support, replace (\d{2}),(\d{3}) with $1.$2 so commas inside the subtitle text are left alone.
- Save as yourfile.vtt with UTF-8 encoding.
Method 2: one ffmpeg command
If you have ffmpeg installed, the whole conversion is: ffmpeg -i subtitles.srt subtitles.vtt. It handles the header, the separators and the encoding in one step, entirely offline. The same command works in reverse (ffmpeg -i subtitles.vtt subtitles.srt) when a desktop player wants SRT back.
Method 3: a client-side browser tool
Some browser tools process files locally with JavaScript, meaning the file is read in your tab and never sent to a server. If you go this route, look for an explicit statement that processing is client-side; 'free online converter' alone doesn't guarantee it. The privacy properties are then the same as a text editor: nothing leaves your device.
Why fix the SRT before you convert?
Conversion copies timestamps verbatim, so an out-of-sync SRT becomes an equally out-of-sync VTT. And once you're in VTT-land, good editors are scarcer; the SRT ecosystem is where the convenient tooling lives. So the sane order is: perfect the SRT, then convert as the final step.
That's where SubtitleShift fits. It's a free, browser-based SRT editor that runs entirely client-side, so the subtitle file never leaves your device. Load the SRT, bulk-shift the timing if captions run early or late, fix typos with find-and-replace or inline edits, and export a clean UTF-8 SRT. Then apply any of the three conversion methods above to produce your VTT. The free tier covers files up to 50 subtitles; a one-time $4.99 Pro upgrade unlocks unlimited subtitles, video preview and range selection.
How do I check that my VTT file is valid?
- Line one reads exactly 'WEBVTT' with a blank line after it.
- Every timestamp uses periods before the milliseconds, with ' --> ' between start and end.
- The file is saved as UTF-8; accented characters and non-Latin scripts display correctly.
- The quickest real-world test: attach it to a <video> element with a <track> tag, or drag it into a player that accepts VTT, and confirm captions appear.
SRT to VTT is a two-change conversion: a header and a punctuation swap. The part worth your attention isn't the conversion itself, it's making sure the subtitles are clean and in sync before you convert, so you only do the job once.
Frequently asked questions
What is the difference between SRT and VTT?
They're close cousins. VTT (WebVTT) starts with a required 'WEBVTT' header line, uses a period instead of a comma in timestamps (00:01:42.300 vs 00:01:42,300), makes cue numbers optional, and adds web features SRT lacks: CSS styling, cue positioning, and NOTE comments. SRT is the older, simpler format that almost every desktop player accepts.
Can I convert SRT to VTT without uploading my file to a website?
Yes, three ways: edit the file by hand in any text editor (add the WEBVTT header, swap timestamp commas for periods), run one ffmpeg command (ffmpeg -i subs.srt subs.vtt), or use a browser tool that runs client-side so the file never leaves your device. For confidential or unreleased content, any of these beats an upload-based converter.
Why do browsers need VTT instead of SRT?
The HTML5 <track> element, which adds captions to a native <video> player, only officially supports WebVTT. Desktop players like VLC, Plex and Kodi happily read SRT, but if you're embedding video on a web page, the captions track needs to be a .vtt file.
Does converting SRT to VTT change the subtitle timing?
No. The timestamps keep the same values; only the separator changes from a comma to a period. If your captions are out of sync before conversion, they'll be exactly as out of sync afterward. Fix the timing in the SRT first, then convert, because SRT editors are far more common than VTT editors.
Will formatting tags like italics survive the conversion?
Mostly yes. Both formats understand <i>, <b> and <u>, so basic tags carry over as-is. SRT font color tags (<font color=...>) have no direct VTT equivalent, though; VTT does color through CSS classes instead, so those need rewriting by hand if you rely on them.
Do I need to convert VTT back to SRT for VLC or Plex?
Usually not; modern versions of VLC, Plex and Kodi read VTT files. But SRT remains the safest universal choice for desktop and TV players, and some older or embedded players still reject VTT. A practical rule: keep an SRT as your master copy, generate a VTT from it whenever the web needs one.