The SRT file format, explained with real examples

SRT is the plain-text subtitle format that refuses to die. It has no official specification, no governing body, and a syntax you can learn in ninety seconds, and yet every video platform, player, and editing tool on earth accepts it. If you work with video, captions, or transcripts, you will meet .srt files constantly, and the difference between meeting them confidently and fighting them comes down to a handful of rules this guide covers completely.

What an SRT file is

SRT stands for SubRip Text, named for SubRip, the early-2000s Windows program that ripped hardcoded subtitles out of video using OCR. SubRip itself is a historical footnote; its output format conquered the world. An SRT file is nothing more than a UTF-8 text file containing numbered blocks of timed text, which is exactly why it won: anything can read it, anything can write it, and a human can fix it in Notepad.

What SRT is not: a styling format. It carries when text appears and what the text says, with only token support for how it looks. That single limitation explains most of the other formats in this space, and we will get to them.

Anatomy of an SRT block

Here is a complete, valid SRT file with two subtitles:

1
00:00:01,000 --> 00:00:03,400
Welcome back to the channel.

2
00:00:03,600 --> 00:00:07,150
Today we are talking about subtitle formats,
starting with the one you already use.

Every block has exactly four parts, in order:

1. A sequence number. Starts at 1, counts up. Players mostly ignore it, but tools expect it, so keep it sequential.
2. A timing line. Start and end time separated by --> (space, two hyphens, right angle bracket, space).
3. The text. One or two lines by convention; nothing in the format stops you writing five, but players will make it look bad.
4. A blank line. This is the block terminator. Forgetting it is the single most common way to corrupt an SRT file.

The timestamp format, precisely

Timestamps in SRT are HH:MM:SS,mmm, hours, minutes, seconds, and milliseconds, with two digits for hours and a comma before the milliseconds:

00:04:07,250 --> 00:04:09,900

That comma is the detail that bites everyone at least once, because nearly every other timestamp format on earth uses a period. It is a French decimal separator, inherited from SubRip's author, and it is mandatory: a period there is technically invalid SRT, and while forgiving players accept it, strict tools and platform validators reject it. When a subtitle upload fails mysteriously, check the commas first.

Three more timing rules that matter in practice:

• End times are exclusive and must be after start times. A zero-length or negative cue is invalid.
• Blocks should not overlap. Some players tolerate overlapping cues by stacking them; many just misbehave. If you need two simultaneous captions (a speaker and a translation), you want a richer format, not overlapping SRT.
• Hours are required. 04:07,250 with no hour field is invalid, even for a short clip. Write 00:04:07,250.

Styling: the little that exists

Styling in SRT amounts to a small set of inline tags, inherited informally from HTML:

3
00:00:08,000 --> 00:00:10,500
<i>This line is italic.</i>
<b>This one is bold.</b>

Italics (<i>), bold (<b>), underline (<u>), and a font color tag (<font color=\"#ff0000\">) make up the entire officially-tolerated set, and support varies by player: VLC renders them, many web players strip them, and some platforms reject files that contain them. Practical advice: use italics for off-screen voices and nothing else, and if your captions need real typography, positioning, or karaoke effects, SRT is the wrong container (see the format comparison below).

A positioning hack exists in the wild ({\\an8} at the start of a line to top-align, borrowed from ASS format) and works in VLC and several desktop players. It is not standard, and web players ignore it, so treat it as a local convenience, not something to ship.

Encoding: the invisible failure mode

An SRT file is text, and text means encoding, and encoding is where subtitles silently break. For anything you create today, the rule is simple: UTF-8, no BOM. Legacy files from the DVD era arrive in Windows-1252 and a dozen regional encodings, which is why a downloaded subtitle file sometimes renders é where é belongs. If you see mojibake like that, the file is fine and the encoding declaration is wrong: re-open it as the right legacy encoding and save as UTF-8. Players have gotten better at guessing, but platform upload validators mostly do not guess, they reject.

Writing an SRT file by hand

Hand-writing SRT for a short clip is entirely reasonable, and doing it once teaches the format better than any guide. Here is the whole workflow: open a text editor, play the video, and write blocks as you go. A template to start from:

1
00:00:00,000 --> 00:00:02,500
[First caption here]

2
00:00:02,500 --> 00:00:05,000
[Second caption here]

Save as whatever.srt, and it works. Hand-writing stops being reasonable somewhere around the two-minute mark of video, which is where the next two sections come in.

Generating SRT from a transcript

Today the path to an SRT file is not typing timestamps, it is transcribing the video and exporting. Any transcript with per-segment timing can become SRT mechanically, and tools that transcribe video, including TranscriptFetch's free Video Transcript Generator, produce timestamped segments exactly for this reason.

Developers can do the transformation from API segments to a valid SRT file in a dozen lines with the official SDK:

# pip install transcriptfetch-sdk
from transcriptfetch import TranscriptFetch

# Reads TRANSCRIPTFETCH_API_KEY from the environment
tf = TranscriptFetch()

def ts(seconds: float) -> str:
    ms = int(round(seconds * 1000))
    h, rem = divmod(ms, 3_600_000)
    m, rem = divmod(rem, 60_000)
    s, ms = divmod(rem, 1000)
    return f\"{h:02}:{m:02}:{s:02},{ms:03}\"  # comma, not period

result = tf.transcripts.get(
    url=\"https://www.youtube.com/watch?v=dQw4w9WgXcQ\",
    timestamps=\"s\",
)

blocks = []
for i, seg in enumerate(result.segments, start=1):
    end = seg.start + seg.duration
    blocks.append(f\"{i}\\n{ts(seg.start)} --> {ts(end)}\\n{seg.text}\\n\")

with open(\"captions.srt\", \"w\", encoding=\"utf-8\") as f:
    f.write(\"\\n\".join(blocks))

The same code works for any platform the Video Transcript API supports, YouTube, TikTok, Instagram, Spotify, or a direct media file URL, which turns "make subtitles for this" into a pipeline step instead of an afternoon.

SRT vs VTT: the comparison that actually matters

WebVTT (.vtt) is SRT's web-native successor, standardized by the W3C for the HTML5 <track> element, and the two formats are close enough that confusing them is routine. The visible differences:

One short decision rule covers it: the open web wants VTT, everything else is happier with SRT. If you are attaching captions to an HTML5 video player, VTT is the only format browsers render natively. If you are uploading to editing tools, or archiving, SRT remains the least-rejected format in existence, and major platforms like YouTube accept both. Since the formats are structurally identical, converting between them is mechanical: add or remove the WEBVTT header and swap the millisecond separator, which is why every subtitle tool offers the conversion for free and you should never pay for it.

The rest of the subtitle format zoo

Subtitle file formats beyond the big two exist for good reasons, and knowing the map saves you from fighting the wrong one:

• ASS/SSA (.ass): the power format from the anime fansubbing world. Full typography, precise positioning, animation, karaoke timing. Overkill for captions, unmatched for styled subtitles. Desktop players render it fully; the web does not.
• SBV: YouTube's old simple format, still accepted by YouTube. Similar to SRT with different timestamps. No reason to author it today.
• TTML/DFXP: XML-based, used in broadcast and streaming delivery pipelines and some legal captioning contexts. You will encounter it as a delivery requirement, not by choice.
• Embedded formats: subtitles can also live inside containers (mov_text in MP4, subtitle tracks in MKV) rather than as sidecar files. Tools like FFmpeg extract them back out to SRT in one command.

If you are choosing, the guidance stays boring: SRT for compatibility, VTT for the web, ASS when styling is the point, TTML when a contract says so.

Opening, editing, and checking SRT files

Any text editor opens an SRT file, which is the format's superpower: rename to .txt if your editor is fussy, edit, rename back. When you want timed editing against the video, dedicated subtitle editors (Subtitle Edit on Windows, Aegisub cross-platform) show waveforms and preview timing. To watch a video with a sidecar SRT, name the file identically to the video (lecture.mp4 + lecture.srt) in the same folder and most players load it automatically; in VLC you can also add one at runtime.

Before shipping a file, a thirty-second validation pass catches nearly everything: sequential numbers, comma separators, --> arrows with spaces, no overlapping times, a blank line after every block, and UTF-8 encoding. Every platform rejection we have seen traces back to one of those six.

Common SRT errors and their one-line fixes

• File rejected on upload: period instead of comma in timestamps, or a stray BOM. Fix the separators, save as UTF-8.
• Captions show as one giant block: missing blank lines between blocks. Re-add the terminators.
• Accented characters render as garbage: legacy encoding. Re-open with the correct encoding, save as UTF-8.
• Subtitles drift out of sync over time: frame-rate mismatch from a converted video. Subtitle editors have a "change frame rate" resync for exactly this.
• Subtitles all appear late by the same amount: constant offset. Every subtitle editor can shift all timestamps by a fixed delta.
• Player shows nothing at all: wrong file pairing (name mismatch), or the file is actually VTT with an .srt extension. Check the first line for WEBVTT.

Where SRT fits in a transcript workflow

A subtitle file is one projection of a transcript, and usually the second one you need: the first is plain text for reading, repurposing, and feeding to AI tools, and the timing data is what upgrades that text into captions. This is why it pays to transcribe once with timestamps and derive everything else, rather than generating captions and reverse-engineering text out of them. The same segments that became SRT above are also the quotes with timecodes in your show notes and the input to a clip-finding script; the podcast version of that workflow, with its own conventions, is covered in podcast transcript format.

The format has outlived the program it was named for by two decades because it does one job with maximum compatibility and minimum ceremony. Learn the four-part block, respect the comma, ship UTF-8, and the format will never surprise you again.