SubRip Subtitle

File structure anatomy

Each subtitle block contains exactly four components:

1
00:02:17,440 --> 00:02:20,375
Senator, we're making
our final approach into Coruscant.

2
00:02:20,476 --> 00:02:22,501
Very good, Lieutenant.

Line 1: Sequence counter. A positive integer starting at 1. Most players ignore this number entirely and rely on timecode order instead. Gaps or duplicates rarely cause failures, but some editors use the counter for navigation.

Line 2: Timecode range. Start and end times separated by --> (spaces around the arrow are required by convention). The format is HH:MM:SS,mmm — hours, minutes, seconds, and comma-separated milliseconds. That comma, not a period, is the single most common source of SRT parsing failures when files are hand-edited.

Lines 3+: Subtitle text. One or more lines of display text. Most players wrap at two lines. There is no hard limit, but text beyond three lines typically overflows the safe area.

Blank line: Block delimiter. An empty line separates blocks. Missing blank lines cause parsers to merge blocks; extra blank lines between blocks are usually tolerated.

The French connection

The comma in 00:02:17,440 is not arbitrary. In French numeric convention, the comma serves as the decimal separator — where English writes 3.14, French writes 3,14. Brain built SubRip in France, and the timecode format inherited this convention directly. Every SRT file written since 1999 carries this French fingerprint. WebVTT, its successor, switched to a period (00:02:17.440), which is one of several reasons the two formats are not drop-in replaceable despite looking nearly identical.

The encoding minefield

SRT has no encoding declaration mechanism. There is no byte-order mark requirement, no header field, no metadata block. The original SubRip software ran on Windows and produced Windows-1252 encoded files. That encoding covers Western European characters but fails on Arabic, Chinese, Japanese, Korean, Cyrillic, and most other scripts.

YouTube requires UTF-8 for SRT uploads. Matroska (MKV) containers mandate UTF-8 for embedded subtitle streams. FFmpeg defaults to UTF-8 when extracting or converting SRT. But a subtitle file downloaded from a fan-translation site, ripped from a DVD-era release, or exported from older subtitle software is almost certainly Windows-1252 or the local system codepage.

The practical result: garbled characters. Accented letters in French or Spanish render as mojibake. Arabic or CJK text disappears or displays as replacement characters. The fix is explicit re-encoding — iconv, recode, or a text editor's "Reopen with Encoding" function. Subtitle Edit detects encoding heuristically and offers one-click conversion to UTF-8 with BOM, which is the safest portable choice.

Formatting extensions

The core SRT format is plain text with no styling. In practice, many players support a subset of HTML-like tags:

• <b>bold</b> — supported by VLC, YouTube, most media players
• <i>italic</i> — widely supported
• <u>underline</u> — less consistently supported
• <font color="#FFFF00">colored text</font> — VLC and some players honor this; YouTube strips it

A positioning extension using coordinate tags ({\an8} or X1:nnn X2:nnn Y1:nnn Y2:nnn appended to the timecode line) exists in some implementations. VLC supports the {\an} positional tags borrowed from SSA/ASS syntax. YouTube ignores all positioning.

None of these extensions are standardized. A file that looks correct in VLC may render as raw HTML tags in another player. This inconsistency is the primary motivation behind WebVTT's formalized styling model.

WebVTT: the intended successor

In 2010, the WHATWG proposed a web-native subtitle format initially called "WebSRT" — a direct nod to SubRip's dominance. The format was renamed WebVTT (Web Video Text Tracks) before standardization. WebVTT inherits SRT's basic structure (timecoded text blocks) but adds a required WEBVTT header, replaces the comma with a period in timecodes, defines CSS-based styling via ::cue selectors, and supports positioning through explicit percentage-based coordinates.

HTML5's <track> element requires WebVTT. SRT cannot be used with <track> without conversion. This means every web-native video player that uses the standard HTML5 subtitle API needs VTT files, not SRT. YouTube accepts SRT uploads but converts them to a proprietary timed-text format server-side. Browser-based players that appear to support SRT are typically running a JavaScript shim that parses SRT and renders the text outside the native <track> pipeline.

Platform compatibility

YouTube added SRT support on August 28, 2008, making it the first major platform to accept user-uploaded subtitles. Facebook requires a specific filename convention: filename.en_US.srt for English (US). Vimeo, Twitter/X, and LinkedIn all accept SRT uploads. VLC, mpv, MPC-HC, and PotPlayer handle SRT natively, both as external sidecar files and as streams embedded in MKV containers.

YouTube added WebVTT support in April 2013. Firefox shipped native WebVTT rendering in Firefox 31 on July 24, 2014. By that point, WebVTT had a formal spec and browser vendor buy-in, but SRT's installed base — millions of subtitle files already distributed — ensured the older format's continued dominance for file-based distribution.

Limitations and why they persist

The absence of a formal specification means every SRT implementation is a best-effort interpretation. Edge cases — overlapping timecodes, missing sequence numbers, inconsistent line endings, BOM bytes mid-file, HTML tags in players that do not support them — produce different results in different players. There is no authoritative reference to consult when two players disagree.

SRT carries no metadata: no language tag, no font specification, no author field, no version number. When you embed an SRT stream in an MKV container, the language tag comes from the container, not the subtitle file. A standalone .srt file gives no machine-readable indication of what language it contains.

Character encoding remains the format's deepest structural weakness. Twenty-five years after its creation, a format used by millions of files worldwide still has no standard way to declare its own encoding. UTF-8 has won by platform mandate (YouTube, MKV, FFmpeg), but the long tail of legacy files encoded in Windows-1252, Shift-JIS, EUC-KR, and GB2312 guarantees that encoding detection heuristics will remain necessary for years to come.