SRT vs VTT: the subtitle format differences that matter
One uses commas, the other periods, and only one of them can position text on screen. Here is what actually separates SRT from WebVTT, and which one your platform wants.
7 minute read
The short answer
Use SRT when the platform asks for it, use WebVTT when the video plays in a browser, and stop worrying about the choice beyond that. SRT is the lowest common denominator: almost every service that accepts a caption file accepts it, and very little can go wrong in it because there is almost nothing in it. WebVTT is the format the web itself runs on, and it carries positioning, styling and structure that SRT has no way to express. People get stuck here because they assume one format is newer and therefore better. They are different tools with different jobs, and in practice the platform you are uploading to has already made the decision for you.
Where each format came from, and why that still shows
WebVTT is a W3C specification. The current text, WebVTT: The Web Video Text Tracks Format, is a Candidate Recommendation Draft dated 20 May 2026, which means there is a written, versioned definition of exactly what a valid file looks like and what every feature does. SRT has nothing like that. It spread out of a Windows subtitle-ripping utility, SubRip, and became universal purely by adoption, with no standards body and no formal grammar. The practical consequence is that SRT parsers quietly disagree at the edges: how much whitespace is tolerated, whether inline tags mean anything, what happens when a cue overlaps the next one. With WebVTT you can look up the answer. With SRT you test it.
The syntax differences you will hit in a text editor
Three things separate the files when you open them. First, the decimal separator in timestamps: SRT writes 00:00:04,500 with a comma, WebVTT writes 00:00:04.500 with a period. That single character is the most common reason a converted file is rejected. Second, WebVTT files must begin with the string WEBVTT, followed by two or more line breaks before the first cue; an SRT file simply begins with the first cue's number. Third, WebVTT mandates UTF-8 encoding, optionally with a byte order mark, while SRT's encoding is whatever the tool that wrote it happened to use, which is where mangled accented characters come from. WebVTT also lets you drop the hours field and lets cue identifiers be optional.
What WebVTT can do that SRT cannot
This is the real gap, and it is not small. WebVTT lets each cue carry settings written on the timestamp line that control where the text sits: line, position, size, alignment, and vertical writing direction. It defines region blocks, which group cues into a box with its own width, line count, anchor and scroll behaviour. It supports STYLE blocks holding actual CSS between the header and the first cue, styling cues through the ::cue pseudo-element. It has NOTE blocks for comments the player never renders, a tag for marking which speaker is talking, and track kinds beyond subtitles for chapters and for time-aligned metadata. SRT has none of this. It has cue numbers, timestamps and text.
Which platforms accept which
YouTube is the most permissive: its help page lists SubRip, WebVTT, SubViewer, SAMI, RealText, TTML and DFXP, plus broadcast formats like Scenarist and EBU-STL. It also documents the ceiling on each, which is the useful part. For SRT it says only basic versions are supported and no style markup is recognised. For WebVTT it says positioning is supported but styling is limited to bold, italic and underline. Vimeo accepts two formats only, WebVTT and SRT. LinkedIn's help page has you attach an SRT during upload, before the post goes out. X documents uploading a .srt caption file. Facebook wants SRT named with a locale, as filename.en_US.srt. Browsers accept WebVTT and nothing else through the video track element.
Converting between them, and what gets lost
Renaming the file does not work. Going from SRT to WebVTT means swapping every comma in a timestamp for a period and adding the WEBVTT header with a blank line under it, and that is genuinely most of it, which is why so many one-click converters exist. Going the other way is lossy in a way people underestimate. Cue settings, region blocks, STYLE blocks and NOTE comments have no SRT equivalent at all, so a converter either drops them silently or writes them into the text as visible junk. Check the first and last cue of any converted file before uploading. Timestamp drift and a stray header line rendered as subtitle text are both common and both obvious once you look.
For vertical clips, the format question mostly goes away
None of this matters much for TikTok, Reels and Shorts, because caption files are not really how short-form works. TikTok and Instagram do not document a caption-file upload for an ordinary post at all; both transcribe on the platform and let you edit the text there. Feeds autoplay muted, so the text has to be visible by default, and the styling you want is nothing WebVTT could describe anyway. Burn it into the pixels and the format question disappears. Keep a caption file for the long-form upload, where it feeds search and the transcript panel. Tools built for clipping, FrameOS included, produce both from the same transcript, which is the only reason the long-form file ever actually gets made.
FAQ
Can I just rename an .srt file to .vtt?
No. A WebVTT file has to start with the string WEBVTT followed by a blank line, and its timestamps use a period before the milliseconds where SRT uses a comma. Renaming alone leaves both problems in place, and most players will reject the file or show nothing. Run it through a converter, then open the result and check the first cue.
Which subtitle format should I upload to YouTube?
Either works, so pick by what you need. YouTube's own documentation says SRT support is basic and no style markup is recognised, while WebVTT supports positioning with styling limited to bold, italic and underline. If you just need accurate timed text, SRT is fine. If you need to move captions off something on screen, use WebVTT. For full styling control YouTube also accepts TTML.
Does SRT support colours, fonts or positioning?
Not dependably. There is no specification for SRT, so any styling is a convention some players honour and others ignore. YouTube states plainly that it recognises no style information in SRT files. If you need control over how the text looks or where it sits, use WebVTT or TTML for a caption track, or burn the text into the video.
What is the difference between VTT and WebVTT?
Nothing. WebVTT is the format's name and .vtt is its file extension, so the two terms are used interchangeably. The full title is WebVTT: The Web Video Text Tracks Format, published by the W3C. If a tool offers you a VTT export, it is producing a WebVTT file.
Sources
- WebVTT: The Web Video Text Tracks Format · W3C
- Supported subtitle and closed caption files · YouTube Help
- Troubleshooting: Caption file types · Vimeo Help Center
- Add Closed Captions to Videos on LinkedIn · LinkedIn Help
- <track>: The Embed Text Track element · MDN Web Docs
Related pages
Keep reading
More Video Basics →Social media video specs for every platform
One 1080x1920 export covers most of short-form. This is where that stops being true — the length caps, file limits, and the platforms where the number changes depending on how you upload.
8 minute readSocial media image sizes for every platform
Instagram's help page now allows 3:4, YouTube's recommended thumbnail is 4K, and TikTok publishes almost nothing. Here are the numbers each platform actually documents, and where they leave you guessing.
7 minute readHow to convert landscape video to vertical
A full-height 9:16 crop of a 1920x1080 frame is 607 pixels wide. Which third of the picture you keep, and whether it is allowed to move, is the entire job.
8 minute readTurn one long video into a week of posts
300 credits for 3 days · no card.
Start free