DesiCaptionsSRT vs VTT vs ASS
Three formats, one decision. Here is the short version and the reasoning behind it.
Short answer
Use SRT. It works in every editor and on every platform that takes a subtitle file, which is why it is the safe default.
Use VTT only when the video plays on your own website. Use ASS only when the caption styling itself matters, such as word-by-word highlighting, and remember no social platform accepts it. For Reels, Shorts and TikTok, no file works at all: you burn the captions into the video.
Every subtitle tool offers to export SRT, VTT, and sometimes ASS, with no explanation of the difference. The choice matters more than it looks: pick wrong and you either lose all your styling or hand a client a file their system rejects.
The short version: use SRT unless you have a specific reason not to. Use VTT for web players. Use ASS when the styling is the point.
Side by side
| SRT | VTT | ASS | |
|---|---|---|---|
| Full name | SubRip Subtitle | WebVTT | Advanced SubStation Alpha |
| Styling | None, basic bold and italic at most | Limited, via CSS-like cues | Full: fonts, colours, outlines, position, animation |
| Positioning | No | Yes | Yes, pixel precise |
| Karaoke and word timing | No | Partial | Yes |
| YouTube | Yes | Yes | No |
| Instagram and TikTok | Not directly, burn in instead | No | No |
| Premiere, Final Cut, Resolve | Yes | Yes | Yes, with varying fidelity |
| HTML5 video | No | Yes, this is its purpose | No |
| Safe default | Yes | For web only | Only when styling matters |
SRT: the one that works everywhere
SRT is the oldest and simplest of the three. A cue number, a start and end timestamp, the text, and a blank line. That is the entire format.
Its limitation is its strength. Because it carries no styling, nothing can go wrong in translation between systems, and essentially every editor, platform, and player accepts it. When you send an SRT to a client, it will open.
Choose SRT for YouTube uploads, for handing files to an editor, for archival, and any time you are not sure. Note the milliseconds separator is a comma, not a full stop. A file using full stops is the single most common reason an SRT gets rejected.
VTT: the one built for browsers
WebVTT was designed for the HTML5 video element. If captions are going to play on your own website, VTT is the correct answer and SRT will simply not load.
It is close to SRT in structure, with two differences that trip people up: the file must begin with the line WEBVTT, and timestamps use a full stop before the milliseconds rather than a comma. Renaming an .srt to .vtt does not convert it.
VTT also supports positioning and simple styling, which is useful when a caption would otherwise cover a logo or a lower third.
ASS: the one that carries the look
Advanced SubStation Alpha stores styling as part of the subtitle data: typeface, size, primary and outline colour, shadow, rotation, exact screen position, and timed effects including karaoke-style word highlighting.
This is the format behind the caption styles you see on Reels and Shorts, where each word pops as it is spoken. That effect is impossible in SRT, which has no concept of a word within a cue.
The catch is support. No social platform accepts an ASS upload. Its real use is as an intermediate: you keep the styling in ASS, render it into the video, and publish the rendered file. If you are handing work to an editor who will do the final render in Premiere or Resolve, ASS preserves your design in a way SRT cannot.
What each file actually looks like
Opening one in a text editor removes most of the mystery, and it is the fastest way to spot why a file is being rejected.
SRT
A number, a time range, the text, then a blank line. That blank line is not optional, and a missing one is the most common reason a file fails to load.
1
00:00:01,240 --> 00:00:03,100
Haan doston, aaj hum banayenge
2
00:00:03,220 --> 00:00:05,900
ek simple recipe jo sabko pasand aayegiVTT
Nearly identical, with two differences that matter: the WEBVTT header, and a full stop rather than a comma before the milliseconds.
WEBVTT
00:00:01.240 --> 00:00:03.100
Haan doston, aaj hum banayengeASS
A different shape entirely. A header defines named styles, then each line references one. This is what lets the file carry its own look.
[V4+ Styles]
Style: Pop,Montserrat,64,&H00FFFFFF,&H00000000,-1,0,3,2
[Events]
Dialogue: 0,0:00:01.24,0:00:03.10,Pop,,0,0,0,,Haan doston, aaj hum banayengeIf a file is being refused, check these three things first: the comma against full stop in the timestamps, the blank line between cues, and whether a stray WEBVTT header ended up in a file named .srt.
Converting between them
Renaming the file does not convert it. The timestamp punctuation and the header differ, so a renamed file is simply a broken file with a new extension.
- SRT to VTT. Add a WEBVTT line at the top and change every timestamp comma to a full stop. Any subtitle tool does this in one step.
- ASS to SRT. The styling is discarded, since SRT cannot express it. Keep the ASS file, because that conversion is one directional.
- Anything to burned-in. This is a render, not a conversion. The text becomes pixels and can no longer be edited or switched off.
The cleaner route is to avoid converting at all. Generate the formats you need from the same transcript, so each one is produced directly rather than degraded from another.
Encoding, and why captions turn into boxes
A subtitle file is plain text, and plain text needs an encoding: the rule that maps bytes to characters. Get it wrong and the words arrive as question marks, boxes, or nonsense symbols.
Save as UTF-8 without a byte order mark. UTF-8 covers every script. The byte order mark is a few invisible bytes some Windows editors add at the start, and several players read them as part of the first cue number, which breaks the entire file.
This bites hardest with Devanagari, where the viewer also needs a font containing those glyphs. Roman-script captions avoid the whole class of problem, since plain Latin characters render correctly in essentially any encoding and any font. That tradeoff is covered in the guide on Devanagari against Roman script.
What to pick, by where the video is going
- Instagram Reels, TikTok, YouTube Shorts. None of them take a subtitle file for short-form. Burn the captions into the video. Keep an SRT alongside for repurposing later.
- YouTube long form. Upload an SRT. YouTube captions are indexed by search, so a real subtitle file is worth more to you than burned-in text.
- Your own website. VTT, no alternative.
- Handing to an editor or client. SRT for safety. Add ASS as well if the caption styling is part of what you are delivering.
- Archive and repurposing. SRT. It will still open in ten years.
A practical habit: export both a burned-in video and an SRT for every project. The video ships today, and the SRT is what lets you cut the same footage into a different format next month without re-transcribing it. Our SRT file generator produces both from one upload, so keeping the pair costs you nothing extra.
A note on Hindi and Hinglish captions
Format choice interacts with script choice. Devanagari text in an SRT depends on the player having a font that renders it, and on the file being saved as UTF-8. Get either wrong and the viewer sees boxes.
Roman-script Hindi sidesteps that entirely. "kya baat hai" is plain Latin characters, which every font and every platform on earth renders correctly, in every one of these three formats. It is one of the reasons DesiCaptions writes Hinglish and Hindi captions in Roman script rather than Devanagari.