What Is an SRT File? Format Structure Explained

Anatomy of an SRT File

Every SRT file follows the same four-line repeating pattern. Understanding this pattern is the key to reading, editing, and debugging subtitle files manually. Here is one complete SRT entry:

1
00:00:01,000 --> 00:00:04,500
This is the first subtitle line.

2
00:00:05,200 --> 00:00:08,800
This is the second line.
It can span multiple rows.

Each entry has exactly four components, and every SRT parser in existence expects them in this order:

• Cue number:A sequential integer starting at 1. Some players ignore this number entirely and rely on timestamp order, but most SRT editors expect it. If you renumber entries incorrectly, some players will display subtitles out of order.
• Timestamp line:Two timestamps separated by the arrow marker -->. The format is HH:MM:SS,mmm where the comma before milliseconds is mandatory. Using a dot instead of a comma is the single most common SRT syntax error and the reason many files fail to load in strict parsers.
• Subtitle text:One or more lines of visible dialogue. Most players support up to two lines. A third line is technically valid but often overflows on small screens. SRT supports basic HTML-like tags (<b>, <i>, <u>) for bold, italic, and underline, though support varies by player.
• Blank line separator:A mandatory empty line between entries. This is how parsers know where one cue ends and the next begins. Missing blank lines cause entries to merge, which is another frequent source of broken SRT files.

Why SRT Became the Default Subtitle Format

SRT files have no binary encoding, no headers, no metadata blocks, and no styling language. They are plain text that can be opened in any text editor on any operating system. That simplicity is the reason the SRT format survived while more complex competitors from the same era did not.

When subtitle files needed to move between Windows, macOS, and Linux in the early 2000s, SRT was the only format that worked everywhere without conversion. That cross-platform compatibility created a network effect: because every player supported SRT, every transcription tool exported SRT, and because every tool exported SRT, every new player added SRT support first.

Today, SRT remains the default working format in most subtitle workflows. Professional transcription services deliver SRT. YouTube accepts SRT uploads. Video editors import SRT natively. Even when a project eventually needs a different format like WebVTT for browser playback or ASS for styled fansubs, the subtitle work usually starts as an SRT file and gets converted later.

Where SRT Files Are Used

The one major gap is browser-based video. HTML5 video players use WebVTT instead of SRT for native caption rendering. If your subtitle file is headed for a website, course platform, or any browser-based player, converting SRT to VTT is a necessary step in the delivery workflow.

What SRT Cannot Do

Understanding the SRT format also means understanding its boundaries. SRT is deliberately minimal, and that minimalism has real trade-offs in production workflows:

• No positioning control:SRT subtitles always appear at the bottom center of the video frame. You cannot place text at the top, move it to avoid overlapping graphics, or position speaker labels on different sides of the screen. If subtitle placement matters, ASS or WebVTT are better choices.
• No font or color styling:While some players support basic HTML tags in SRT for bold, italic, and color, this support is inconsistent. There is no official styling specification, and most platforms strip these tags during import.
• No metadata or headers:SRT has no place to store information about the video, language, author, or encoding. The file is raw subtitle data with nothing else. This means language detection, for example, must be done by reading the text content rather than from a declared metadata field.
• No karaoke or animation:If your subtitle workflow involves karaoke timing, progressive text reveal, fade effects, or any visual animation, SRT is not the right format. ASS (Advanced SubStation Alpha) is the standard choice for those use cases.

Common SRT File Problems and How to Fix Them

SRT files break more often than people expect, usually because of small syntax mistakes that are invisible until the file hits a strict parser. These are the most frequent issues:

• Dot instead of comma in timestamps

  The SRT specification requires a comma before milliseconds: 00:01:23,456. WebVTT uses a dot. If someone hand-edits an SRT file and uses dots, or if a tool exports with the wrong punctuation, strict parsers will reject the file. This is the number one reason SRT files silently fail to load.

• Wrong character encoding

  SRT files should be saved as UTF-8, especially when they contain non-Latin characters like Chinese, Japanese, Korean, Arabic, or accented European text. Files saved in legacy encodings like Windows-1252 or Shift-JIS will display garbled characters in players that expect UTF-8. If subtitles appear as question marks or random symbols, encoding is almost always the cause.

• Missing blank lines between entries

  Every SRT entry must be followed by an empty line. Without it, the parser cannot tell where one cue ends and the next begins. The result is usually merged entries or subtitles that display at the wrong time.

• BOM (Byte Order Mark) at the start of the file

  Some text editors on Windows insert an invisible BOM character at the beginning of UTF-8 files. This can cause the first cue number to be misread, making the first subtitle entry invisible or misaligned. Saving the file as “UTF-8 without BOM” fixes this.

• Overlapping timestamps

  When two entries have time ranges that overlap, players handle it differently. Some show both lines simultaneously, some show only the later entry, and some skip one entirely. If subtitles disappear unexpectedly, check for timestamp overlaps.

SRT Compared to Other Subtitle Formats

For a deeper comparison between SRT and VTT, including when to convert and when not to, read the full SRT vs VTT comparison guide. For ASS versus SRT trade-offs in fansub and styled subtitle workflows, see the ASS vs SRT guide.

When You Need to Convert an SRT File

SRT is a strong working format, but it is not always the right delivery format. These are the situations where converting an SRT file is the correct next step:

• Web video delivery: HTML5 video players require WebVTT. If your SRT file is going into a website, course platform, or browser-based player, convert SRT to VTT before embedding.
• Translation or text review: When translators or reviewers need the dialogue without timestamp noise, extract text with SRT to TXT to produce a clean transcript.
• Receiving non-SRT files: If someone sends you an ASS or VTT file and your workflow expects SRT, use ASS to SRT or VTT to SRT to standardize the file.
• Creating subtitles from scratch: If you have a script, transcript, or lyrics but no timed subtitle file, use TXT to SRT to generate a subtitle draft with auto-generated timestamps.