You built a beautiful page with a self-hosted video. You added your .srt subtitles via the <track> element. You open it in Chrome — subtitles work. You open it in Safari — nothing. Welcome to the reason WebVTT exists.

The HTML standard for browser subtitles is WebVTT (.vtt), and while some browsers tolerate SRT, Safari and Firefox have historically refused it. If your video plays on the open web, VTT isn’t optional — it’s the format. Our free SRT to VTT converter does the rewrite in your browser instantly. Here’s the full picture.

Why the web standardized on VTT

SRT is from 1999 — a DVD-ripper-era format that became the world’s most common subtitle file by accident. When the W3C designed subtitle support for HTML5 video, they didn’t adopt SRT; they created WebVTT, designed for the web from the start:

  • Styling and positioning. VTT cues can carry alignment, position, size, and text styling. SRT is plain text with timing — no layout control at all.
  • Metadata and chapters. VTT supports chapter tracks, description tracks for screen readers, and metadata cues. SRT has one job: dialogue timing.
  • Streaming-friendly. VTT segments cleanly for HLS and DASH adaptive streaming, where subtitle chunks are delivered alongside video chunks. SRT was never designed for that.
  • Proper spec, proper parsing. SRT’s “spec” is really just “what SubRip did.” VTT has a real specification, which means consistent parsing across players.

The practical upshot: SRT is the interchange format, VTT is the web format. Generate or receive SRT, convert to VTT for the player. (Need the reverse trip? Our VTT to SRT converter handles it.)

The conversion, line by line

Given this SRT block:

1
00:00:12,500 --> 00:00:15,000
Welcome to the tutorial.

The VTT equivalent is:

WEBVTT

00:00:12.500 --> 00:00:15.000
Welcome to the tutorial.

Three mechanical changes, as the FAQ says: header added, commas become periods, block number dropped. Nothing about the words or timing changes. This is why conversion is instant and safe — it’s text rewriting, not re-interpretation.

Serving VTT correctly (the part everyone misses)

Converting the file is step one. Getting browsers to use it involves two more details that trip people up:

The <track> element. The standard markup:

<video controls>
  <source src="lesson.mp4" type="video/mp4">
  <track src="lesson.vtt" kind="subtitles" srclang="en" label="English" default>
</video>

kind="subtitles" (not "captions" — that’s for the hearing-impaired track convention), srclang matching the language, and default if it should be on initially.

The MIME type. Your server must serve .vtt files as text/vtt. Most static hosts (Netlify, Vercel, Cloudflare Pages) do this out of the box now; some older servers and misconfigured CDNs serve text/plain, and a few strict players then refuse the file. If subtitles work locally but not on your live site, the MIME type is the first suspect.

CORS. If the video and the VTT live on different domains, the track element needs CORS headers on the subtitle file. Keep them on the same origin and skip the headache.

When VTT’s extra features earn their keep

For plain dialogue, VTT and SRT are interchangeable. VTT pulls ahead in three cases:

  1. Positioned subtitles. Two speakers, and you want each one’s lines on their side of the screen: align:start position:0% vs align:end position:100%. SRT can’t do this at all.
  2. Styled emphasis. <b>, <i>, <u>, and <c.classname> for colored or styled spans — handy for speaker differentiation or emphasis without burned-in graphics.
  3. Multi-track video. One video, five languages: five VTT files, five <track> elements, and the browser offers a subtitle menu automatically. This is the same multilingual pattern from our SRT generation guide — VTT is just the web-native carrier.

A caution: don’t go overboard with styling. Viewers can override subtitle appearance in their player settings, and heavy custom styling fights those preferences. Position and speaker labels: yes. Rainbow-colored karaoke: no.

A real example: the course platform migration

A creator moves 30 tutorial videos from YouTube to a self-hosted course site (built with a static host and a Video.js player). She downloads the SRT files from YouTube Studio — good, those exist. She wires up <track> elements pointing at the .srt files. Testing: Chrome shows subtitles, Safari shows nothing, and the support inbox fills up.

The fix:

  1. Batch-convert all 30 files with the SRT to VTT converter — each takes seconds.
  2. Rename references from .srt to .vtt in the track elements.
  3. Verify the host serves text/vtt (it does — modern static hosts do).
  4. Retest in Safari and Firefox: subtitles everywhere.

Total time: under an hour for 30 videos. The alternative — re-generating subtitles or debugging per-browser SRT quirks — would have eaten a weekend.

How to convert in your browser

  1. Open the SRT to VTT converter.
  2. Paste your SRT text or drop in the .srt file.
  3. Download the .vtt — proper WEBVTT header, period timestamps, UTF-8.

Then wire it into your <track> element, check the MIME type, and test in Safari — not just Chrome. If your subtitles need to travel further (an editor that only takes SRT, a platform with its own validator), keep the original SRT alongside the VTT. Formats are cheap; regeneration is expensive. Convert free with the SRT to VTT tool.