How to Convert SRT to VTT for HTML5 Video

Why Convert SRT to VTT

SRT is the workhorse subtitle format — it has been around since the 1990s and almost every player understands it. But when you embed video on the web with an HTML5 track element, the format browsers natively understand is WebVTT. Some browsers and many video platforms are lenient and accept SRT files, but the reliable, standards-compliant choice is VTT. Beyond raw compatibility, VTT is a richer format: it supports cue styling, positioning, regions, and settings that SRT cannot express. If you are building a video page, adding captions for accessibility, or uploading subtitles to a platform that requires VTT, converting is the step that turns a working file into a standards-correct one. VTT is also the format most caption tooling and accessibility checkers expect, so using it avoids a class of integration problems later. Accessibility is the strongest argument of all: captions are a documented requirement for synchronized media under the WCAG guidelines, and the way to deliver them in a browser is a track element pointing at a VTT file. In short, SRT is fine for local players, VTT is what the web speaks.

What Actually Differs Between the Formats

The two formats share the same basic structure — a sequence of cues, each with a start time, an end time, and some text — but the syntax differs in ways that matter. SRT uses commas to separate milliseconds, like 00:00:01,000, while VTT uses dots, like 00:00:01.000. SRT has no header at all; VTT begins with the line WEBVTT, and strict parsers reject a file that lacks it. VTT also has an extended syntax SRT does not: inline cue settings after the timestamp for positioning, cue identifiers above the timing line, and blocks such as STYLE, REGION, and NOTE that carry metadata the player can use. Most VTT files you produce will look structurally similar to their SRT source, which is exactly why hand-converting one to the other is so easy to get subtly wrong. The conversion is mostly a header, a punctuation swap, and small normalizations, and a converter gets all of them right in one pass. Getting those details wrong is the difference between captions that appear and captions that silently never show. A file that fails to parse usually fails quietly, leaving you with a video that plays fine and no subtitles at all.

When You Would Convert SRT to VTT

You need VTT any time the destination expects WebVTT. The most common case is a website or course platform that uses HTML5 video with a track element for captions — that is the standard, accessible way to add subtitles, and it works best with VTT. Learning platforms, video portfolios, and internal training videos all run on this pattern, and captions are often a requirement rather than an option: the WCAG accessibility guidelines ask for captions on synchronized media, which many public-sector and enterprise sites must meet. You might also be handed a draft SRT from a transcriptionist or a machine-transcription service and need it converted to feed into your own player. Subtitles for a podcast or webinar replay that gets posted to a video host are another common source. Because the SRT to VTT converter works entirely in the browser, you can also convert the subtitle track of an unreleased video without uploading the file to a third-party service — the captions never leave your device, which matters when the video is still under embargo. Localization teams converting caption tracks for new language versions also work with VTT at the delivery stage on many platforms.

How to Convert SRT to VTT

The converter reads your SRT file, parses every cue, and re-serializes it as VTT — adding the WEBVTT header, swapping comma milliseconds for dot milliseconds, and dropping anything VTT does not need. A preview table lets you confirm the timing and text parsed correctly before you download.

1. 1Open the SRT to VTT converter
2. 2Drag your .srt file onto the drop zone, or paste the subtitle text and click Convert to VTT
3. 3Check the cue preview to confirm timestamps and text parsed correctly
4. 4Review the output — it should start with WEBVTT and use dot milliseconds
5. 5Download the .vtt file and attach it to your track element with kind and srclang set
6. 6Spot-check a few timestamps in the player to confirm sync

Fixing Timing Problems Before You Convert

A converted file is only useful if the timing is right, and the SRT to VTT converter ships with timing tools that fix the common problems before export. Constant shift moves every cue earlier or later by a set number of milliseconds — exactly what you need when one stream has a fixed lag. Frame-rate resync handles linear drift, where cues are perfect at the start but slip further off as the video plays, usually because a track was timed for one frame rate and played at another; you supply the source and target rates and the tool stretches the timing accordingly. Two-point sync aligns the first and last cue to known-correct times, which rescues a re-cut video where only the endpoints are reliable. Merge cues joins short neighboring cues whose gaps fall within a small window, cleaning up a subtitle file that was split into too many fragments. These tools operate on the parsed cues before serialization, so you fix the timing once and export clean VTT instead of editing timestamps by hand. Hand-editing timestamps across hundreds of cues is exactly the kind of error-prone chore that causes more drift, so fixing it in the tool is both faster and more reliable.

Common Mistakes and Edge Cases

Several small details trip people up when converting subtitles. Sending an SRT that uses comma milliseconds and no header to a strict player will fail silently or show no captions — the converter fixes both, but only if you actually use the converted file rather than renaming an SRT to have a .vtt extension. A byte-order mark or unusual line endings at the start of a file can also break parsing; dropping the file into the tool rather than hand-editing avoids that whole class of problems. Very long cues can be split or skipped by some players, so it is worth checking for cues that run far beyond a few seconds. Text containing angle brackets can render oddly; the converter strips markup that VTT does not support. And if you are starting from ASS subtitles with heavy styling, convert to SRT first and then to VTT rather than expecting the styling to survive. Do not forget that the track element needs matching kind and srclang attributes to display, and that some players require a separate WebVTT text track even when they accept SRT — the video will not show captions otherwise. When in doubt, the preview table shows every cue with its start time, end time, and text, so problems are visible before you download.

Privacy: Subtitles Never Leave Your Device

Everything about this conversion happens in your browser. The SRT file is read locally with JavaScript, the parsing and re-serialization run in memory on your device, and no data is sent to any server. That makes the tool safe for subtitle tracks from unreleased videos, client work under a non-disclosure agreement, or any material you would rather not have sitting in a third-party upload queue. The same is true of the timing tools — shifting, resyncing, and merging all operate on the parsed cues locally, so the entire workflow stays on your machine. When you download the .vtt file, that is the only moment the converted content exists as a file outside the page, and you are the one who created it. There is no account, no upload history, and no server-side copy of your caption track that you have to remember to delete. If you are working with content that cannot legally leave your building, this local-only design means you can convert captions without a second thought about where the file traveled on its way to the output. Caption tracks can carry entire transcripts of your video, so treating them as private content is often the right call.

A Closer Look at the VTT Syntax

Reading the actual output of a conversion makes the format differences concrete. A minimal VTT file produced from an SRT source looks like this: the first line is WEBVTT, followed by a blank line, then a cue such as 00:00:01.000 --> 00:00:04.000 followed by the dialogue text, then another blank line before the next cue. Note the dot before the milliseconds and the two-digit hours, both required by the WebVTT spec and both different from SRT. VTT goes further with syntax SRT simply does not have. A cue can carry settings after its end timestamp, such as align:start position:10% to pin it to the left side of the screen, or line:80% to push it near the bottom. A line above the timestamp can be a cue identifier, which lets a script reference that specific cue. Blocks at the top of the file can define styles for cue text, regions that place cues on part of the screen, and NOTE comments that carry metadata such as the source file or the translator's name. SRT expresses none of this; a conversion cannot invent it, which is why the converter outputs clean, standard VTT with the same text and timing rather than trying to guess what styling you wanted. For most uses that plain output is exactly right.

Accessibility and the Track Element

Captions are not an optional extra on the web — they are how video becomes usable for viewers who are deaf or hard of hearing, and they are a documented requirement under the WCAG accessibility guidelines for synchronized media. Delivering them in a browser means a track element inside the video element, pointing at a VTT file. The track element takes three attributes that get captions working: src points at the .vtt file, kind tells the browser it is a captions track, and srclang declares the language, such as en or es, so viewers can pick it from the player's menu. A common oversight is the label attribute, which controls the friendly name shown in that menu — captions that are technically present but badly labeled are hard for viewers to find. Another is assuming one track is enough: providing a second language track or a no-captions option is normal for multilingual sites. Browsers parse VTT leniently, but a malformed file simply produces no captions with no error visible, which makes the post-conversion spot check essential. When the track element, the VTT file, and the language attributes all line up, captions appear in the player automatically and meet the accessibility requirement.