SRT Generator + Guide: What Is an SRT File and How to Create One (2026)

TL;DR — pick your path

What is an SRT file?

An SRT file — short for SubRip Subtitle — is a plain-text file that carries subtitles or captions for video. Each subtitle is called a cue, and every cue has four parts: a sequence number, a start-to-end timestamp, one or two lines of text, and a blank line before the next cue.

Structure of a valid SRT

1
00:00:01,200 --> 00:00:03,800
First line of subtitle text.

2
00:00:04,000 --> 00:00:06,500
Second cue, optionally on
two lines maximum.

3
00:00:07,000 --> 00:00:09,200
Third cue.

The timestamp format is HH:MM:SS,mmm — hours, minutes, seconds, and three-digit milliseconds — separated by --> (two hyphens and a greater-than sign, with a space on each side). Note the comma separating seconds from milliseconds — this is one of the two differences from WebVTT (which uses a period).

Where SRT came from

SubRip was a Windows tool released around 2001 by Zuggy that extracted subtitles from DVDs by optical character recognition. Its default output used the .srt extension, and the format spread from there. SRT was never formally standardized by any body (W3C, ISO, IETF) — it’s a de factostandard defined by what the SubRip tool produced and what other software agreed to accept. Edge cases (line breaks, encoding, styling tags) vary across implementations because there’s no formal spec to reference.

What SRT files are used for

• YouTube caption uploads — YouTube accepts SRT and other formats for creator-uploaded captions
• Video editor imports — Premiere Pro, DaVinci Resolve, Final Cut Pro all import SRT natively
• Standalone video playback — VLC, MPV, mpv, PotPlayer, and TV streaming apps auto-load SRT files with matching filenames
• Streaming platform delivery — some platforms accept SRT; broadcast typically requires SCC or TTML/DFXP
• Translation source — you translate the text of an SRT for multi-language distribution

What SRT files are NOT

• Not a web standard — HTML5 <track> requires WebVTT
• Not a broadcast standard — US broadcast uses SCC (EIA-608/708)
• Not a styling format — the little styling SRT supports (<b>, <i>) is inconsistently rendered
• Not tied to a video — the SRT is a separate file; the video player pairs them at playback

SRT file size reality

SRT files are tiny. A 60-minute video with dense dialogue produces an SRT of 30–80 KB. Even a 3-hour film transcript rarely exceeds 200 KB. If your SRT is over 1 MB, something’s wrong — usually duplicate cues or an unexpected encoding issue.

What is a VTT file?

A VTT file — short for WebVTT (Web Video Text Tracks)— is the W3C-standardized subtitle file format for web video. It’s SRT’s modern sibling: same underlying idea (timed text cues), but with a proper specification, CSS styling support, and native HTML5 compatibility.

Structure of a valid VTT

WEBVTT

1
00:00:01.200 --> 00:00:03.800
First line of subtitle text.

2
00:00:04.000 --> 00:00:06.500
Second cue, optionally on
two lines maximum.

NOTE This is a comment, ignored by players.

3
00:00:07.000 --> 00:00:09.200 align:center line:80%
Third cue with positioning.

Three visible differences from SRT:

1. A required WEBVTT header on the first line
2. A period for milliseconds (not comma): 00:00:01.200
3. Optional cue settings after the timestamp for positioning and styling

Where VTT came from

WebVTT was proposed by the WHATWG in 2010 as the caption format for HTML5 <video>. The W3C standardized it in WebVTT 1.0 (2019). Unlike SRT, VTT has a formal specification that browsers and players implement consistently.

What VTT adds over SRT

• Native HTML5 support — VTT works directly with <track> elements in any modern browser
• Positioning — cues can specify horizontal and vertical alignment (align:, line:)
• CSS styling — target cues with ::cue pseudo-elements for full styling control
• Chapter cues — separate from subtitle tracks, used for video chapter markers
• Metadata cues — JSON payloads triggered at specific timestamps (used in interactive video)
• Comments — NOTE blocks that players ignore
• Voice tags — <v Speaker Name> for speaker identification

Where VTT is used

• HTML5 <video> — the only officially supported caption format for HTML5
• Podcasting 2.0 — <podcast:transcript> RSS tag typically points to a VTT file. See Podcast Transcription.
• Streaming platform captions — many platforms accept VTT
• Modern video players — video.js, Plyr, Shaka Player all support VTT natively

Basic VTT with styling

WEBVTT

STYLE
::cue {
  color: yellow;
  background-color: rgba(0, 0, 0, 0.6);
  font-family: sans-serif;
}
::cue(.speaker-a) {
  color: cyan;
}

1
00:00:01.000 --> 00:00:03.000
<c.speaker-a>Hello, world.</c>

2
00:00:03.500 --> 00:00:05.500
This cue uses default styling.

SRT vs VTT — the practical differences

Which one should you use?

• Web video (HTML5 <video>): VTT. It’s the only officially supported format.
• YouTube / Vimeo / streaming platforms: Either — SRT is simpler and more universal.
• Video editing (Premiere, DaVinci, FCP): SRT — universal, simple.
• Podcasting 2.0: VTT is recommended by the spec; SRT works too.
• Broadcast delivery: Neither — use SCC or TTML/DFXP.
• Need custom styling / positioning: VTT.

Converting between them

SRT to VTT is nearly trivial — add a WEBVTT header and change commas to periods in timestamps:

# Bash / macOS / Linux
echo "WEBVTT" > output.vtt
sed 's/,/./g' input.srt >> output.vtt

# Or FFmpeg (works both directions)
ffmpeg -i input.srt output.vtt
ffmpeg -i input.vtt output.srt

VTT-to-SRT strips VTT-only features (positioning cues, CSS styling, chapter tracks, comments) but preserves the base cues cleanly.

SRT vs SBV, SCC, TTML, ASS — the full landscape

SRT and VTT dominate consumer use, but several other subtitle formats exist for specific contexts.

For the accessibility framing behind these formats (open/closed/SDH), see What Is Closed Captioning?

The 4 ways to generate an SRT (ranked by use case)

There’s no single “best” tool — it depends on how much you’re subtitling, what languages you need, and how much time you’re willing to spend on the terminal.

1. YouTube auto-caption + download

Upload your video to YouTube as unlisted, wait 5–30 minutes for auto-captions to finish, then download the .srtfrom Subtitles → the three-dot menu → Download. Free, no account needed beyond a Google login. Quality is mediocre on anything noisier than a clean voiceover, and “unlisted” is not private — anyone with the URL can watch.

2. Subtitle Edit (desktop)

Subtitle Edit is a free Windows app (Mac/Linux via Wine) that loads audio, shows a waveform, and lets you type subtitles cue-by-cue. It also has built-in support for offline Whisper inference if you install the model. Best for fine-tuning timing on an existing SRT, not for generating from scratch.

3. Self-hosted Whisper

OpenAI’s Whisper model runs locally with one command if you have Python:

pip install openai-whisper
whisper input.mp4 --model large-v3 --output_format srt

Free, fully private, and accurate. The catch: on a CPU, expect 10–30× real-time (a 1-hour file takes 10–30 hours). On a recent GPU it’s real-time or faster. Worth it for sensitive content; not worth it for a single 5-minute clip.

4. AI transcription with native SRT export (DeluxeScribe)

Services like DeluxeScribe upload, transcribe, and export SRT in one flow. You get accurate timing because the model produces word-level timestamps the SRT generator can group into properly sized cues. Cost is the tradeoff against free options. Full audio-to-SRT workflow: Audio to SRT. Full video-to-SRT: Video to SRT.

The timing rules that make an SRT usable

A “valid” SRT (one your player accepts) and a readable SRT are different things. Netflix, the BBC, and most major broadcasters share a small set of rules that distinguish professional captions from auto-generated ones.

Reading speed: 17 CPS (adult), 20 CPS (children)

Characters per second. Netflix uses 17 CPS for adult-targeted content; the BBC allows up to 20 CPS for shorter on-screen durations. Above ~25 CPS, viewers can’t finish reading before the cue disappears. Auto-caption tools usually ignore this and dump entire sentences into 1.2 seconds.

Line length: 42 characters maximum

42 characters is the Netflix standard; the BBC uses 37–39 for broadcast. Going wider risks wrapping mid-word, getting clipped at the edges of widescreen TVs, or overlapping with on-screen graphics.

Two lines per cue, maximum

Three-line cues exist but they’re a sign something else is wrong — usually a cue duration that should have been split into two. Modern guides treat two lines as a hard ceiling.

Minimum 2-frame gap between cues

Cues that touch (one ends, the next starts the same frame) cause visual flicker on broadcast and some video players. The BBC mandates at least 2 frames of gap (~83ms at 24fps). For web video this is less critical but still cleaner.

Why these matter even if your player accepts the file:YouTube’s caption review will flag cues that exceed reading speed. Broadcasters reject submissions that violate them. Viewers complain about unreadable captions long before they file format-spec bugs.

Character encoding — the universal gotcha

The most common SRT failure isn’t timing or format — it’s character encoding. Because SRT was never formally standardized, the format doesn’t specify an encoding. Different tools produce different encodings, and different players handle them differently.

What can go wrong

• Accented characters (é, ü, ñ, ç) show as garbage: é, ü, ñ
• Non-Latin scripts (Chinese, Japanese, Arabic, Cyrillic) show as boxes or question marks
• First cue displays extra characters like  (a UTF-8 BOM misinterpreted)
• Player fails to load the file entirely with an “invalid encoding” error

The three common SRT encodings

How to check and fix encoding

VS Code (easiest)

Open the SRT. Look at the bottom-right corner — it shows the current encoding (e.g., UTF-8 or Windows 1252). Click it, choose Save with Encoding → UTF-8. This saves without a BOM by default.

Notepad++ (Windows)

Encoding menu → Convert to UTF-8(not “Convert to UTF-8 with BOM”). Save.

Command line (macOS / Linux)

# Detect current encoding
file input.srt

# Convert from Windows-1252 to UTF-8
iconv -f WINDOWS-1252 -t UTF-8 input.srt > output.srt

# Strip a UTF-8 BOM
sed -i '1s/^\xef\xbb\xbf//' input.srt

Why UTF-8 without BOM is the right choice

• Handles every character in every script (Chinese, Arabic, Cyrillic, emoji, etc.)
• No BOM means players don’t misinterpret the first bytes as content
• Every modern SRT-consuming tool (YouTube, Premiere, VLC, browsers) handles it correctly
• Cross-platform compatible without conversion

Save as UTF-8 without BOM. Every time. This single rule eliminates about 80% of subtitle rendering issues.

Translating an SRT without breaking timing

The wrong way: paste the entire .srt into Google Translate. It mangles timecodes and cue numbers because translation models rewrite numbers, drop blank lines, and sometimes merge cues. You end up with a broken file.

The right way: translate only the text content, preserving the structure. Tools that do this properly (Subtitle Edit’s built-in translate, DeluxeScribe’s SRT export with translateTo, dedicated tools like SubtitleCat) parse the SRT, send each text segment separately for translation, then reassemble with the original timecodes intact.

One catch: character expansion. German is ~30% longer than English; Arabic is ~25% shorter. If your reading speed was 17 CPS in English, the German translation may exceed 25 CPS in the same cue duration. The professional fix is to split long cues into multiple shorter ones — the lazy fix is to extend cue durations until they overlap the next one.

Why your SRT looks broken (5 common fixes)

Garbled accented characters (é shows as é)

Encoding issue. See encoding section above — save as UTF-8 without BOM.

Subtitles drift off-sync after a few minutes

Frame-rate mismatch. The SRT was generated for 23.976 fps but you’re playing 24 fps (or vice versa). Use Subtitle Edit’s “Change frame rate” tool, or recalculate with FFmpeg: ffmpeg -i in.srt -r 23.976 out.srt.

VLC doesn’t show subtitles automatically

VLC auto-loads SRT files only when they share the video’s base name. my-video.mp4 needs my-video.srt in the same folder. Otherwise, drag the SRT onto VLC after starting playback.

YouTube rejects the upload

Usually one of three things: missing blank line between cues, no trailing newline at the end of the file, or a Byte Order Mark on the first cue. Open in a text editor with visible whitespace and check.

Long lines wrap mid-word in the player

You’ve got cues longer than 42 characters per line. Either insert manual line breaks at sensible word boundaries, or regenerate with a tool that respects line length limits. Avoid trying to fix this with CSS — most players ignore it.