Subtitle Formats Explained: SRT vs VTT vs ASS, and Burned-In

Subtitles look like a solved problem until a file refuses to load, the accents turn into question marks, or the text drifts a second out of sync halfway through. Nearly all of those failures come from choosing the wrong format for the destination, and they are easy to avoid once the differences are clear.

The Formats

SRT — SubRip

The universal exchange format: a plain text file of numbered blocks with start and end timecodes.

1
00:00:01,500 --> 00:00:04,000
The first line of dialogue.

2
00:00:04,200 --> 00:00:07,100
And the second one.

It carries no styling beyond basic bold, italic and underline, and no positioning. That limitation is exactly why it works everywhere — every player, platform and editing tool accepts it. Note the comma before the milliseconds; this is the detail that most often breaks conversions.

Use it for: uploading to YouTube, Vimeo and social platforms, sending to a translator, or any situation where you do not control the player.

WebVTT — the web standard

Built for HTML5 video and required by the <track> element. Structurally close to SRT with three differences that matter: the file must begin with the line WEBVTT, timecodes use a full stop rather than a comma before the milliseconds, and it supports cue positioning, alignment and CSS styling.

WEBVTT

00:00:01.500 --> 00:00:04.000 line:90% align:center
The first line of dialogue.

Use it for: video embedded in a web page, HLS streaming, anywhere the browser is the player.

ASS / SSA — Advanced SubStation Alpha

A full styling language: named styles, fonts, colors, outlines and shadows, precise positioning, rotation, karaoke timing and animation. Used heavily in anime fansubbing and anywhere subtitles are part of the visual design.

The power comes with fragility. ASS renders correctly only where the required fonts exist and the player implements the format properly — which many hardware players and platforms do not. Upload an ASS file to a platform expecting SRT and the styling tags typically appear as literal text.

Use it for: local playback and cases where typography carries meaning. Convert to SRT for distribution.

SUB / IDX — image-based

Rather than text, these store bitmap pictures of each subtitle, as ripped from DVDs. The consequence is that they cannot be searched, edited, restyled or translated without optical character recognition, and they carry the resolution they were authored at. Blu-ray uses a similar image-based format, PGS.

Comparison

Format	Styling	Positioning	Compatibility	Best for
SRT	Minimal	No	Universal	Uploading, exchange, translation
WebVTT	CSS	Yes	Browsers, HLS	Web players
ASS/SSA	Extensive	Precise	Limited	Local playback, styled typography
SUB/IDX	Fixed image	Fixed	Media players	DVD rips only

Soft, Embedded or Burned In?

Three distinct ways subtitles reach the viewer:

• External (soft) — a separate file alongside the video. The viewer can switch it off, restyle it, or choose another language. Requires the player to find and load it, and the file can be lost when the video is shared.
• Embedded (muxed) — the subtitle track is stored inside the container, typically MKV or MP4, still as switchable text. Travels with the file, remains optional, and is added without re-encoding the video.
• Burned in (hardcoded) — the text is rendered into the video frames themselves. It cannot be turned off, disabled or translated, and it requires re-encoding.

Burning in is the right choice in exactly one situation, but it is a common one: social platforms that autoplay muted. On Instagram, TikTok, Reels and much of Facebook, most viewers never enable sound and no subtitle track is offered — if the text is not in the picture, it does not exist. Everywhere else, keep subtitles as a separate or embedded track so viewers retain control and search engines can read the text.

The Details That Break Files

Character encoding

If accented characters, Cyrillic or Asian text appear as ? or garbage, the file was saved in a legacy single-byte encoding such as Windows-1251 or Latin-1. Save subtitles as UTF-8, and preferably without a byte order mark — a BOM at the start of an SRT file confuses some parsers into rejecting the first cue.

Timecode punctuation

SRT uses a comma before milliseconds (00:00:01,500); WebVTT uses a full stop (00:00:01.500). Renaming an .srt to .vtt does not convert it — the header is missing and the punctuation is wrong, so the browser loads nothing.

Frame rate mismatch

Subtitles that start in sync and drift steadily worse were timed against a different frame rate — typically 23.976 fps versus 25 fps, a 4.3 % difference. That accumulates to about two and a half seconds after an hour. A constant offset, by contrast, means the subtitles simply start early or late and need a single shift. Drift needs rescaling; offset needs shifting. Diagnosing which one you have saves a great deal of manual editing.

Overlapping cues

When one cue ends after the next begins, players behave inconsistently — some overlay both, some drop one. Most subtitle tools flag overlaps automatically, and it is worth fixing them before distribution.

Readability Rules

Broadcast subtitling standards exist because they measurably improve comprehension:

• Two lines maximum, ideally under 42 characters each. Three-line subtitles cover too much of the frame and outpace reading speed.
• Reading speed of 15–20 characters per second. A full two-line subtitle needs roughly 4–6 seconds on screen.
• Minimum duration around 1 second, even for a single word — anything shorter registers as a flash.
• Break lines at natural grammatical boundaries. Split between clauses, not between an article and its noun.
• Match cuts. A subtitle spanning a scene change is disorienting; end it on the cut where possible.
• Keep an outline or a semi-transparent box. White text alone disappears against a bright sky.

A Practical Workflow

1. Generate a draft automatically. Speech recognition gets most of the words and, more importantly, gets the timings approximately right — which is the tedious part. Automatic captioning produces the first pass.
2. Correct the text. Names, technical terms and homophones are where recognition fails. Numbers and punctuation usually need attention too.
3. Fix the timing, then check line lengths and reading speed against the rules above.
4. Translate if needed, from the corrected file rather than the raw transcript — errors propagate into every language otherwise. Translating the subtitle file preserves the timing structure while replacing the text.
5. Deliver in the right form: SRT for platforms, WebVTT for your own web player, burned in for muted-autoplay social video. Merging subtitles into the video handles both the embedded and burned-in cases.

Why Bother When Platforms Auto-Caption?

Because automatic captions are a starting point, not a deliverable. They mishear proper nouns and technical vocabulary, they punctuate poorly, and they do not respect line-break or reading-speed conventions. Beyond accessibility — which is the primary reason — uploading a corrected subtitle file gives platforms accurate text to index, which affects how the video is found. And a large share of viewers watch with sound off by choice, not necessity.