SRT and VTT look almost identical — what's the real difference?

Structurally they are very similar, but there are three differences: a VTT file starts with a WEBVTT line, it uses a period instead of a comma in timestamps (00:00:01.500), and it supports positioning, alignment and styling cues. Most importantly, the HTML5 video element only accepts VTT — you cannot use an SRT file directly on a web page.

Why does character encoding cause so much trouble?

Because subtitle files are plain text, and text files don't inherently declare which encoding they were saved in. A program has to make an assumption when it opens the file. Turkish subtitles were historically saved in Windows-1254; when a modern tool that assumes UTF-8 reads that file, letters like ş, ğ and ı turn into meaningless characters.

Why does frame rate affect subtitle sync?

Some older subtitle formats store time as a frame number instead of seconds. On top of that, the same film can exist in versions at different frame rates — cinema is 24 fps, PAL television is 25 fps, NTSC is 23.976 fps. If a subtitle prepared for 25 fps is played over a 23.976 fps video, a small error accumulates every second, and after two hours the drift can reach several minutes.

When do you actually need the ASS format?

When the subtitle's position, color, font or movement has to change with the content. For example placing the translation of an on-screen sign right next to that sign, distinguishing different speakers with different colors, or highlighting song lyrics karaoke-style. SRT can do none of these; every line appears in the same style, in the same place.

Subtitle Formats: The Differences Between SRT, VTT and ASS

Subtitle files are simple text files, but the differences between them decide where and how your video will be seen. This article explains the structure of the three common formats, the root of the character encoding problem, and the technical reasons behind sync drift.

SRT: the most common and the simplest

The SubRip Text format takes its name from a DVD subtitle ripping program, and its structure is about as simple as it gets:

1
00:00:01,500 --> 00:00:04,200
Hello, this is the first subtitle line.

2
00:00:04,500 --> 00:00:07,800
This is the second line and
it has been split across two rows.

Each block has four parts:

Sequence number (starting at 1)
Time range (start --> end)
Text (one or more lines)
Blank line (separates the blocks)

The time format is hours:minutes:seconds,milliseconds, and the millisecond separator is a comma. That detail is one of the key distinctions from VTT.

The limits of SRT:

There is no styling information. Font, size, color, position — none of it is defined in the file. The player or the burn-in tool decides these externally.
There is no positioning. Every subtitle appears in the same place (usually bottom center).
Limited formatting. Some players support the <i> (italic), <b> (bold) and <u> (underline) HTML tags, but this isn't a standard feature; not every player interprets them.

In exchange, it has universal support: nearly every player, every television, every subtitle editor reads SRT. Because it's simple, you can edit it by hand in a text editor.

VTT: SRT designed for the web

WebVTT (Web Video Text Tracks) was developed for HTML5 video. It looks a lot like SRT but carries three differences:

WEBVTT

1
00:00:01.500 --> 00:00:04.200
Hello, this is the first subtitle line.

2
00:00:04.500 --> 00:00:07.800 position:50% line:80%
This line is positioned specially.

Difference 1: the WEBVTT header. The file must begin with this line.

Difference 2: the period separator. In timestamps the millisecond separator is a period, not a comma. The simplest way to convert an SRT file to VTT is to add a WEBVTT line at the top and turn the commas into periods.

Difference 3: positioning and styling cues. Values like position, line, align and size can be appended to the timing line. Styling with CSS is also possible.

What really matters about VTT: the HTML5 <video> element only accepts VTT.

<video controls>
  <source src="video.mp4" type="video/mp4">
  <track src="subtitle-tr.vtt" kind="subtitles" srclang="tr" label="Türkçe" default>
  <track src="subtitle-en.vtt" kind="subtitles" srclang="en" label="English">
</video>

This setup has one important advantage: the subtitle text is readable by search engines. A burned-in subtitle is part of the image and machines can't read it; a separate VTT file, on the other hand, is accessible as text.

The kind attribute distinguishes different track types: subtitles (translation), captions (for deaf and hard-of-hearing viewers, including sound effects), descriptions (audio description for blind viewers), chapters (chapter markers).

ASS/SSA: styling power

Advanced SubStation Alpha is a far more complex format, and it carries styling information inside itself:

[Script Info]
ScriptType: v4.00+
PlayResX: 1920
PlayResY: 1080

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, OutlineColour, ...
Style: Default,Arial,48,&H00FFFFFF,&H00000000,...
Style: Sign,Arial,36,&H0000FFFF,&H00000000,...

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Text
Dialogue: 0,0:00:01.50,0:00:04.20,Default,,0,0,0,,Hello.
Dialogue: 0,0:00:05.00,0:00:07.00,Sign,,0,0,0,,{\pos(800,200)}CLOSED

What ASS gives you:

Named styles. Separate styles can be defined for different speakers and different kinds of text.
Free positioning. With \pos(x,y) a subtitle can be placed anywhere on screen.
Color and outline control. Each style carries its own color palette.
Animation. Sliding, fading, rotating, scaling.
Karaoke effects. Highlighting syllables in sequence in song lyrics.
Layers. Subtitles that overlap.

When is it needed? When the subtitle's position, color or movement has to change with the content: putting the translation of an on-screen sign next to that sign, separating speakers by color, highlighting lyrics.

The cost: support isn't as broad as SRT. Some players ignore the styles and show plain text; some won't open it at all.

Character encoding: the classic headache

This is the most frequent problem with non-English subtitles, and it comes straight from the nature of the formats.

Subtitle files are plain text, and text files don't inherently declare which encoding they were saved in. A program has to make an assumption when it opens the file.

Historically, Turkish text was stored in these encodings:

| Encoding | Era | Status | |---|---|---| | ISO-8859-9 (Latin-5) | 1990s-2000s | Legacy | | Windows-1254 | Windows systems | Legacy | | UTF-8 | 2000s onward | Modern standard |

When you read a Windows-1254 file assuming UTF-8, language-specific letters break:

| Correct | Broken appearance | |---|---| | ş | þ or ÅŸ | | ğ | ð or ÄŸ | | ı | ý or Ä± | | İ | Ý or Ä° | | ç | ç | | ü | ü |

The fix: open the file in a text editor and save it again as UTF-8. In Notepad the encoding option sits at the bottom of the Save As dialog; in VS Code the current encoding is shown in the bottom right corner and can be changed by clicking it.

The BOM issue: UTF-8 files may optionally carry a "byte order mark" (BOM) at the start. Some tools misread the first line in files with a BOM. If you run into trouble, try UTF-8 without BOM.

Frame rate and sync drift

Subtitle sync breaks in two distinct ways, and each has its own fix.

Constant offset

The subtitle is consistently early or late by the same amount.

Cause: your video has a section at the beginning that the subtitle file doesn't account for (a distributor logo, a warning screen), or the other way around.

Fix: add or subtract the same value from every timestamp. Subtitle editors do this in a single operation.

Growing drift

Sync is fine at the start but falls apart toward the end.

Cause: a frame rate mismatch. The same content exists in versions at different frame rates:

| Standard | Frame rate | Use | |---|---|---| | Cinema | 24 fps | Film shooting | | PAL | 25 fps | European television | | NTSC | 23.976 fps | Americas, digital distribution | | NTSC video | 29.97 fps | American television |

A subtitle prepared for 25 fps, played over a 23.976 fps video, accumulates roughly 4% error every second. Over a two-hour film that means a drift exceeding five minutes by the end.

Fix: proportional correction. Every timestamp is multiplied by the ratio (target fps / source fps). Subtitle editors offer a "frame rate conversion" option.

Some older formats (like MicroDVD) store time directly as a frame number, not in seconds. In those formats it's impossible to compute time without knowing the frame rate.

Embedding vs. burning: what changes in the file

Embedding (soft subtitle): the subtitle is added to the video container as a separate track. MKV supports this perfectly; support in MP4 is more limited (usually only certain formats). The video data is never touched, so it can be stream-copied and the quality is preserved.

Burning (hardsub): the subtitle is drawn onto every video frame and becomes pixels. This requires the video to be re-encoded — so there is some quality loss.

During burning the subtitle text is permanently lost; only the image remains. Which means:

It can't be undone.
Search engines can't read it.
Screen readers can't access it.
It can't be turned off.

In exchange, you get no compatibility problems at all — the subtitle is now part of the picture.

In summary

SRT is the simplest and most widely supported format, but it carries no style or position information; VTT was designed for the web, it's the only format the HTML5 video element accepts, and being readable by search engines is an extra advantage; ASS offers styling, positioning and animation power but has narrower support. The most common problem with non-English subtitles is character encoding, and the fix is to save the file again as UTF-8. With sync drift, a constant offset is solved by a simple time shift while a growing drift needs a frame-rate-proportional correction. And the choice between embedding and burning is irreversible: burning works everywhere, but the subtitle text is permanently lost.