What Is an SRT File? (And How Do You Read a Subtitle File)

If you have ever downloaded a movie subtitles file, it was almost certainly an SRT. SRT stands for SubRip Subtitle, named after a Windows ripper tool from the early 2000s that extracted subtitles from DVDs. The format stuck, even though SubRip itself has not been actively developed in over a decade. SRT is the lingua franca of subtitles: every video player reads it, every subtitle editor writes it, every conversion tool supports it as a source or target format.

This post walks through what an SRT file looks like, why it has the structure it has, how to read and edit one by hand, and how to convert it to other formats (WebVTT, ASS, SUB) when you need to.

The structure of an SRT file

Open an SRT file in a text editor and you will see something like this:

1
00:00:01,000 --> 00:00:04,000
Welcome to the channel.

2
00:00:04,500 --> 00:00:08,200
Today we are going to talk about subtitles.

3
00:00:08,500 --> 00:00:12,000
Specifically, the SRT format.

Each cue is a block of four things: a number (the cue index), a time range, the text, and a blank line separator. The number is a 1-based counter; players use it for ordering, but most will also accept out-of-order numbers as long as the times are in order. The time range is HH:MM:SS,mmm --> HH:MM:SS,mmm — hours, minutes, seconds, milliseconds. The comma before the milliseconds is a European convention; WebVTT uses a period instead. The text is plain text, one or more lines, and the blank line separates cues.

That is the whole format. No header, no metadata, no encoding declaration. The encoding is usually UTF-8, but older files can be in Windows-1252, which is why you sometimes see garbled characters (the famous "é" instead of "é") in subtitle files.

Why the line breaks look weird

SRT was designed in the early 2000s when most subtitle rendering engines wrapped long lines at a fixed character count. The convention is to wrap subtitle text at around 42-45 characters per line, and to break the line at a word boundary. Most editors will reformat the text to fit a video's width, so a single spoken sentence often becomes two or three lines.

You can also see forced line breaks in the source: if a subtitle editor wants the text to break at a specific point (because the next line will appear on a new line in the video, for example), they insert a hard line break. Hard line breaks show up as actual newlines in the SRT text; soft line breaks (the ones the player adds based on width) are not in the file.

How to read an SRT file

Open it in a text editor. Notepad, TextEdit, VS Code, Sublime — any of them will show the file as plain text. The cue numbers and time codes are easy to scan past; the text is the actual content. To find a specific moment in the video, search for the text and look at the time range above it.

If you want to read the subtitle file alongside the video — see cue 1, then watch the video from 00:00:01 to 00:00:04 — most video players (VLC, mpv, MPC-HC) let you load an SRT file as a separate subtitle track. The subtitle text appears at the bottom of the video, synced to the time codes.

How to edit an SRT file

For small fixes (typos, timing adjustments), editing the file by hand is fine. The format is forgiving: the cue number is not strictly required, the blank line is required, the time format is fixed. Common edits:

• Fix a typo in the text. Just change the text; the time code and number stay the same.
• Shift all timing by 500 ms (the audio is ahead of the subtitles). Open the file in any text editor, use Find and Replace with regex to find (dd):(dd):(dd),(ddd) and add 500 ms to each match. Most editors do not do regex by default, so a script is faster.
• Re-time a single cue. Find the cue by number, change the time range, save.
• Remove a cue. Delete the cue number, the time range, the text, and the blank line. Do not leave an empty blank line behind — many parsers will treat it as a malformed cue.

For larger edits (translation, restructuring, batch retiming), a dedicated subtitle editor like Subtitle Edit (Windows) or Aegisub (cross-platform) is faster.

How to convert SRT to other formats

You will need to convert SRT to WebVTT if you are embedding subtitles in an HTML5 video on a website — the <track> element expects VTT, not SRT. The conversion is mostly a matter of swapping the comma in the time codes for a period, and adding a WEBVTT header at the top of the file. Some tags (italics, bold, font color) carry over; some (positioning, animation) do not, because the two formats have different feature sets.

You will need to convert SRT to ASS or SSA if you are working with anime fansubs, which often use styled subtitles with per-line fonts, colors, and positioning. ASS is a superset of SSA and supports a much richer styling language than SRT. Converting from SRT to ASS usually loses styling (SRT has no styling) but preserves timing and text.

The Uttir Subtitle Converter handles SRT, WebVTT, ASS, SSA, and SUB. The file is parsed and rewritten in the browser, so the content never leaves your device.

The three most common SRT problems

Off-by-one timing. The subtitle appears 1 second late because the time codes are based on a different video frame rate. For a 23.976 fps video, multiply each time by 1.001 to convert to 24 fps timing, or by 0.999 to go the other way. For a 25 fps PAL video vs a 24 fps NTSC video, multiply by 25/24 = 1.0417.

Wrong encoding. The file is in Windows-1252 but you opened it as UTF-8 (or vice versa). Reopen the file in an editor that lets you pick the encoding, or convert the file with a tool like iconv on the command line. The Uttir Subtitle Converter detects common encodings and lets you save in UTF-8 explicitly.

Windows line endings. The file was saved on Windows with CRLF line endings, and a Linux player chokes on the extra carriage return. Most parsers handle this gracefully, but if yours does not, convert the file to LF endings with a tool like dos2unix on the command line or with a "save with LF" toggle in your text editor.

When to use the SRT format (and when not to)

SRT is the right format when you need a simple, widely-supported subtitle file. It works in every video player, every streaming service that accepts user-uploaded subtitles, and every editing tool. It does not support styling beyond basic italics and bold, and it does not support positioning or animation. For those features, you need WebVTT (for web), ASS (for anime-style styled subs), or a broadcast format like STL or EBU-TT.