SRT to VTT Converter

What SRT Is, and Where It Is Used

SubRip Text — .srt — came out of SubRip, a Windows program first released in 2000 that extracted subtitles from DVDs, later reading them with OCR. The format is whatever that program happened to write: a numbered list of cues, each one an index, a timing line, and one or more lines of text, separated by blank lines. There is no standards body behind it and no formal specification. What SRT "is" is defined by what players accept.

That accident of history is also its strength. Twenty-five years of players were written against it, so SRT is the format that works everywhere: VLC, mpv, Plex, every smart TV, Premiere Pro, DaVinci Resolve, Final Cut, YouTube, Vimeo, Facebook, LinkedIn and essentially every "upload your subtitles" box on the internet. If you have one subtitle file and you do not know where it is going, SRT is the safer thing to have.

Styling in SRT is entirely a convention. <i>, <b>, <u> and <font color="#ffcc00"> are widely honoured because the players that grew up alongside the format already understood HTML fragments — not because anything says they should. Positioning is not part of the format at all. An SRT cue appears wherever the player puts cues.

What WebVTT Is, and Where It Is Used

WebVTT — Web Video Text Tracks, .vtt — is a W3C specification written for the web. It is what the HTML5 <track> element parses, and it is the only thing that element parses. Browsers do not read SRT. That single fact is why most people arrive at a converter like this one.

Because it was designed rather than inherited, WebVTT has room for things SubRip never needed. A file opens with the signature line WEBVTT, optionally followed by header metadata. Cue identifiers are optional and can be any text. The hours field is optional, so 00:01.500 is a legal timestamp. After the end time you can put cue settings — line, position, align, size, vertical, region — that place the cue on screen. NOTE blocks are comments. STYLE blocks carry real CSS applied through the ::cue pseudo-element. REGION blocks define scroll-up areas for live captioning. Inside a cue you can mark the speaker with <v Alex>, tag spans with <c.loud> for CSS to target, and time individual words with tags like <00:00:02.500> for karaoke highlighting.

Outside the browser, WebVTT is also the subtitle format of HLS streaming, and the format most JavaScript player libraries expect — hls.js, video.js, Shaka Player, Plyr. If your video is playing inside a web page, the subtitle file is almost certainly WebVTT.

The Exact Differences

Read that table one way and WebVTT is a superset of SubRip. That is the practical rule to remember, and it is what makes the two directions asymmetric: SRT to VTT is lossless, VTT to SRT is not.

How to Convert an SRT File to VTT

1. 1
   Load the subtitle file

   Drop your .srt file onto the converter above, or open it in any text editor and paste the contents in. The converter reads the first line to decide which direction you need — a file beginning with WEBVTT is converted to SubRip, anything else is converted to WebVTT — and you can override that with the direction buttons.
2. 2
   Read what it says it changed

   Below the output the converter lists everything it did beyond swapping decimal separators: a byte-order mark removed, timestamps that had the wrong separator, cue settings or NOTE blocks that SubRip cannot hold. If a timestamp is malformed it stops and names the line number instead of writing a broken file.
3. 3
   Download or copy the result

   Download names the file for you — the original basename with the new extension — and the Copy button puts the whole converted file on your clipboard. Then serve the .vtt file with a Content-Type of text/vtt and point a <track> element at it.

Conversion is instant and happens locally. Nothing is uploaded, so nothing is queued and there is no file-size cost to anyone but your own browser.

When Conversion Loses Information

SRT to VTT: nothing meaningful

Every construct SubRip has, WebVTT also has. Timings survive to the millisecond because both formats store milliseconds. The <i>, <b>, <u> and <font> tags SRT uses by convention are valid WebVTT markup, so cue text passes through untouched. The only changes are structural: the header line is added, commas become periods, and the numeric indices become optional identifiers — which this converter keeps by default, because they cost nothing and they make a diff between the two files readable.

One genuine edge case: WebVTT treats < and & as the start of markup. An SRT cue containing a bare < that is not a tag — a line of dialogue like 3 < 5 — is legal SRT and ambiguous WebVTT. It is rare enough that silently rewriting it would cause more surprises than it prevents, so this converter leaves your text exactly as you wrote it.

VTT to SRT: whatever the web-only parts said

Going the other way, anything WebVTT expresses that SubRip has no room for has to go. Cue settings — the positioning that put a caption at the top of the frame so it would not cover a lower third — are dropped, and the cue lands wherever the player puts cues. REGION and STYLE blocks and their ::cue CSS are dropped. NOTE comments are dropped. Class spans, language spans and ruby annotations are stripped. Inline karaoke timing tags are stripped, because SubRip times whole cues and never individual words, so there is nowhere for that timing to live.

Voice spans are the one case where deleting the markup would delete something the viewer actually needs. A cue reading <v Alex>we should ship it</v> loses the tag but keeps the name as a plain Alex: prefix. Losing the styling hook is a smaller loss than losing who spoke. Non-numeric cue identifiers are dropped too, and every cue is renumbered from 1 — a gap in SubRip numbering is one of the more common reasons a player quietly stops rendering the rest of a file.

The converter reports each of these under the output rather than performing them quietly. A converter that drops your caption positioning without saying so is worse than one that refuses, because you find out from a viewer.

Adding Subtitles to an HTML5 Video

Once you have a .vtt file, adding it to a video is one element. The <track> element goes inside <video>, and you can add one per language:

<video controls width="720" poster="poster.jpg">
  <source src="talk.mp4" type="video/mp4" />

  <!-- The browser will not load a .srt here. It must be WebVTT. -->
  <track
    src="/subtitles/talk.en.vtt"
    kind="captions"
    srclang="en"
    label="English"
    default
  />

  <track
    src="/subtitles/talk.es.vtt"
    kind="subtitles"
    srclang="es"
    label="Espanol"
  />
</video>

• kind — subtitles is a translation for someone who can hear the audio; captions also carries speaker identification and non-speech sound, for someone who cannot. If your file is a transcript of what is said in the video's own language, captions is the honest value and the one assistive technology expects.
• srclang — a BCP-47 language code (en, pt-BR). Required for subtitles. label is the human-readable name shown in the player's menu.
• default — one track per video may carry it. Without it, no track is selected until the viewer opens the subtitle menu, which is why a correct .vtt file often looks like it did nothing.
• Serve it as text/vtt — this is the most common server-side mistake. Some static hosts return text/plain for an unfamiliar extension and browsers refuse the track.
• Cross-origin needs CORS — a track on a different domain (a CDN, an object store) requires CORS headers on the file and crossorigin="anonymous" on the <video> element. Testing over file:// fails for the same reason: browsers treat local files as cross-origin. Run a local server instead.

When the track is loading but nothing shows, the browser console usually says why in one line. When the console is silent and the menu is empty, suspect the BOM — the invisible three bytes some editors put in front of WEBVTT, which stop the parser recognising the signature. The converter on this page strips it.

Three Things That Silently Break a Subtitle File

• The byte-order mark. "UTF-8 with BOM" is a default in several Windows editors. In SRT it usually shows up as a stray character before the first cue number; in WebVTT it hides the signature line and the whole file is rejected.
• The wrong encoding. Older SRT files are frequently Windows-1252 or an ISO-8859 variant. Read as UTF-8, every accented character becomes a replacement character and cannot be recovered afterwards. WebVTT is UTF-8 by specification, with no alternative. If the converter above reports replacement characters, go back to the original file and re-save it as UTF-8 first.
• The missing blank line. Both formats separate cues with a blank line and nothing else. Lose one and a strict parser reads two cues as one, or stops. This converter treats it as an error and names the line, rather than merging the cues and handing you something that looks fine until it plays.

Line endings, by contrast, are mostly a non-issue: the WebVTT specification accepts CRLF, LF and a bare CR, and SRT parsers accept all three in practice because there is no specification to say otherwise. The output here uses LF unless you ask for CRLF, which is worth doing only for older Windows tooling that parses the timing line by fixed offset.

What Valmera Does Instead — and What It Does Not Do

Plainly: Valmera does not import or export SRT or VTT files. This converter is a standalone utility on our site, not a feature of the editor. If your workflow needs a sidecar subtitle file at the end of it, Valmera will not produce one.

What Valmera does is burn captions into the picture. It transcribes your footage with word-level timings and renders the captions as part of the video: 11 presets, 12 bundled font families, karaoke word-pop, per-word emphasis and colour, entrance animations, and an editable transcript that re-renders the captions when you fix a word. None of that is expressible in a sidecar file, because a sidecar file is re-rendered by whatever player opens it, in that player's own style.

That is a real trade-off in both directions, and it is worth being clear about which side you need. Burned-in captions cannot be switched off, cannot be translated by the platform, and are not read by search engines — which is exactly why sidecar files exist. They also cannot be lost, are never mis-served with the wrong MIME type, and look the same everywhere, which is why social platforms are full of them. We wrote both sides up in burned-in captions vs. subtitles, and the caption feature itself is documented on add captions to video.

If what you actually need is the transcript in the first place — you have footage and no subtitle file at all — that is a different job from format conversion. See the auto subtitle generator, or the rest of the editing tools.

Frequently Asked Questions

The Editor Behind the Free Tool

Valmera is an agentic AI video editor: upload real footage, describe the edit in plain English, and an agent performs it. 50 free credits, no card. Captions are burned in — no SRT or VTT export.