SRT vs VTT: which subtitle format should you use?

The short answer: subtitle format comparison

If you only need one line: choose SRT when a person or a desktop editor will open the file next, and choose WebVTT when a browser will play the video. Both formats carry the same basic information — a start time, an end time and the words to display — but they grew up in different places. SRT came from the DivX and DVD-ripping world, where permissive parsers tolerated small mistakes. WebVTT was designed at the W3C for HTML5 video, with a formal syntax and features that a browser can style and position.

That history explains the practical differences you will notice. An SRT file is usually just numbers, timestamps and text. A VTT file starts with a WEBVTT signature and may contain comments, regions, styling blocks and cue settings. Most video tools read SRT; most browsers read VTT natively. Many tools read both, which is why the question keeps coming up.

Timestamp syntax and file structure

The most common conversion bug is the millisecond separator. SRT writes 00:00:07,500 with a comma; WebVTT writes 00:00:07.500 with a period. If you rename an SRT file to .vtt without changing the commas and adding the WEBVTT header, strict players may reject it even though a lenient parser displays something. Subtitles that suddenly stop appearing after a format change usually have this problem.

SRT also puts a sequence number above every cue. The numbers do not control playback order — parsers sort by timestamp — but most editors and validators expect them to be present and sequential. WebVTT allows an identifier line instead, and it can be words rather than digits. In WebVTT the identifier is not shown on screen, so you can use it to label scenes or speakers for your own workflow.

SRT

1
00:00:01,250 --> 00:00:03,500
The train leaves at seven.

2
00:00:04,000 --> 00:00:06,200
Bring the blue folder.

WEBVTT

1
00:00:01.250 --> 00:00:03.500
The train leaves at seven.

2
00:00:04.000 --> 00:00:06.200
Bring the blue folder.

Which subtitle file formats do editors and platforms accept?

Desktop editors are the strongest argument for SRT. Premiere Pro, DaVinci Resolve, Final Cut Pro and CapCut all import SRT in their normal subtitle workflows, and many of them also import VTT. If you are handing a file to a colleague who will open it in an older version of an editor, SRT is the lower-risk choice. It is also what most captioning agencies and courts still request.

Browsers are the strongest argument for VTT. The HTML5 track element expects WebVTT, and Safari, Chrome and Firefox implement it natively. YouTube accepts both SRT and VTT in Studio, but its own caption editor exports SRT. TikTok and Instagram do not accept either file as a direct upload in every workflow; they often expect captions burned into the video or entered in their app. Check the current platform help page before you promise a client a file format, because menus and limits change.

Styling, positioning and cue settings

SRT has no official styling model. People put <i> and <b> tags inside cues, and some players honour them, but the behaviour is not guaranteed. Positioning is even less portable: some tools understand an unofficial X1, X2, Y1, Y2 coordinate line, but the same line can appear as on-screen text in another player. If exact placement matters, SRT is the wrong container.

WebVTT supports cue settings on the timestamp line, including alignment, line position, text position and size. It also defines a STYLE block and CSS-like classes, although browsers restrict which properties apply to captions. This makes VTT the better choice for a web player that needs captions near the top of the frame or left-aligned for a specific layout. The catch is that styling does not travel into most video editors, and a platform may ignore it. Treat styling as a web feature, not a universal subtitle feature.

Encoding, line endings and invisible breakage

Both formats are plain text, so encoding matters more than the extension. Save as UTF-8. A file saved as Windows-1252 will turn Urdu, Arabic, Hindi, Chinese or accented European text into question marks or mojibake even if the timestamps are perfect. Some Windows tools still default to a local code page, so open the exported file in a text editor and confirm that the script looks right before uploading.

Line endings are usually forgiving: CRLF from Windows and LF from macOS both work in modern players, though a few old hardware players prefer CRLF. A UTF-8 byte-order mark at the start of a VTT file can cause the WEBVTT signature to be missed, so strip the BOM if a browser refuses the file. Blank lines matter too. In both formats, a blank line separates cues; deleting them while editing by hand can merge two cues into one.

Which format should I use? A decision path

Start with the destination, not with the format you like. If the file is going into a video editor, a client handoff, a DVD-style workflow or a captioning agency, export SRT. If it is going into an HTML5 player, a web accessibility review or a browser-based caption layer, export VTT. If the destination accepts both, pick SRT for maximum compatibility and convert a copy to VTT only when a web player asks for it.

There are two cases where the decision is less obvious. The first is a platform that accepts both but normalises one: upload SRT if the help page lists it, then check the result on a phone. The second is a project that needs styling. Keep an SRT as the editable master and generate VTT for the web player, so a styling change never forces you to re-time the whole file.

• Editing software, client delivery, archive: SRT.
• HTML5 video, web player, browser captions: WebVTT.
• Both accepted: SRT by default; keep a VTT copy for web use.
• Heavy styling or positioning: keep the master in SRT and publish a styled VTT.

Converting SRT to VTT and back without losing timing

A correct conversion changes the header and timestamp separator, then preserves cue text and timing exactly. SRT-to-VTT conversion is usually safe because VTT is a superset of the basic cue information. VTT-to-SRT is safe for plain cues but can lose information: cue identifiers become numbers, NOTE comments disappear, and cue settings such as align:start have no SRT equivalent. That is why a round-trip test matters. Convert a file there and back, then compare cue count and timestamps instead of assuming the files are identical.

Our SRT to VTT converter performs this conversion in the browser and keeps the original timing in milliseconds. For files with styling, do not treat the converted SRT as a perfect copy of the VTT. Keep the original VTT if you may need its settings again.

Common SRT and VTT failures and how to spot them

A subtitle file can look correct in a text editor and still fail in a player. The fastest diagnosis is to check four things in order: the header, the timestamp separator, the blank lines between cues and the text encoding. If the player shows nothing at all, suspect the header or the extension. If it shows the first cue and then stops, suspect a malformed later timestamp. If it shows commas or numbers on screen, the player is reading the file as plain text rather than as subtitles.

Overlapping cues are a different class of problem. SRT and VTT both allow overlapping times in the file, but many players display only one cue at a time. Two speakers talking over each other therefore need either a combined cue or a deliberate positioning strategy. Run the file through our subtitle validator to catch overlaps, long lines and reading-speed problems before upload.