An SRT caption file is a plain-text subtitle track timed to your video. You can create one by transcribing the finished video, dividing the words into numbered cues, adding start and end timestamps, and saving the file as UTF-8 with an .srt extension.
Here, SRT means SubRip, not Secure Reliable Transport, the separate live-video transport protocol. A caption file does not contain video, and uploading one for a video does not by itself establish that captions will appear during every live simulcast of that video.
Two different meanings of SRT
The shared abbreviation causes confusion because it names two unrelated things. A SubRip SRT file is text: it holds caption cues and timing information that a compatible player or platform can display alongside media. Secure Reliable Transport is a protocol used to carry live video between systems. It is not a subtitle format.
If a setup screen asks for an SRT file, subtitle file, or caption file, it may mean SubRip. If it asks for an SRT URL, stream ID, or passphrase, it is probably referring to the transport protocol. Check the surrounding instructions rather than inferring from the letters alone. Vimeo’s SRT streaming guidance concerns the transport protocol, not how to write caption cues.
This distinction matters when you prepare a pre-recorded programme for a live channel. Your .srt file can accompany the video in an on-demand or archive workflow. Whether those captions are also sent to viewers during a live encoder session depends on the platform and encoder’s caption workflow. Confirm that separately before you rely on the file for live captions.
What a SubRip file contains
A SubRip file is a sequence of caption cues. Each cue has a number, a start and end time, one or more lines of text, and a blank line separating it from the next cue. The file describes when text should be shown; it does not carry the video or audio.
A minimal example looks like this:
1
00:00:02,400 --> 00:00:05,200
Welcome to tonight's programme.
2
00:00:05,600 --> 00:00:08,000
We recorded this session earlier today.
The first cue appears at two seconds and 400 milliseconds, and ends at five seconds and 200 milliseconds. The next begins after a short gap. The example shows the layout, but it does not guarantee acceptance by every platform or prove that captions will be carried in a live stream.
Keep the cue number, timing line and text in that order. Include a blank line after each cue, including the last one if your editor preserves it. Do not add a title, notes for yourself, or formatting that your destination platform does not document. Plain text is easier to inspect when something goes wrong.
Create numbered caption cues
Start with the final version of your transcript. Listen to the actual video rather than relying only on a script: recorded speech may differ from the written copy, and names, pauses or announcements may have changed during editing. Correct the transcript before timing it, then split it into manageable phrases that viewers can read while watching.
Give the first cue the number 1 and increase the number by one for every following cue. Avoid skipped or repeated numbers. Each cue should contain the words or sound information that belongs in that interval. If the file is intended to serve viewers who cannot hear the audio, include meaningful non-speech sounds where appropriate; YouTube’s manual caption guidance gives examples such as [applause] and [thunder].
There is no universal line-length or cue-duration rule established by the sources used for this guide. Aim for readable lines and enough time to follow them, but treat those choices as editorial judgement, not a platform rule. For a bhajan stream, for example, you might divide an introduction into short phrases and keep a song title visible long enough to read, rather than placing an entire spoken introduction into one long cue.
Use punctuation and spelling consistently, and check people’s names and devotional terms against the audio or a reliable reference. If a speaker changes, you can identify the speaker in the text when that helps viewers follow the programme. Avoid turning every small breath or pause into a separate cue; too many brief changes can make captions harder to read.
Format timestamps as hh:mm:ss,mmm
An SRT timing line uses this form:
hh:mm:ss,mmm --> hh:mm:ss,mmm
The hours, minutes and seconds each use two digits, and milliseconds use three. A comma separates seconds from milliseconds. For example, 00:01:12,075 --> 00:01:15,800 starts at one minute, twelve seconds and 75 milliseconds, and ends at one minute, fifteen seconds and 800 milliseconds. The timestamp describes a position on the media timeline, not a clock time of day.
Use leading zeroes where needed. 00:00:05,200 is the expected shape; a variation such as 0:0:5.2 changes the field widths and uses a full stop instead of the comma. Vimeo’s SRT troubleshooting instructions give the same key checks: two digits for hours, minutes and seconds, three for milliseconds, a comma, and a blank line between cues.
Check that each cue’s end is later than its start, and that the cues appear in the intended order. A gap between cues is acceptable when there is silence or no text to display. Do not overlap captions accidentally; if you intend a particular overlap, first check whether the destination workflow supports it as expected.
Synchronise cues to the finished video
Timing must match the actual media that viewers will see. A cut, inserted logo, shortened introduction or changed opening slate can shift every later cue. Work against the final export or the exact file that will be streamed, not a draft that is still being edited.
A practical way to time a cue is to note when the first word begins and when the last word ends, then review the result in the player. Use the target platform’s timeline. Vimeo OTT specifically says to reference media timecode rather than SMPTE timecode; this is guidance for that product’s workflow, not a universal instruction for every platform. If you replace a video there, Vimeo OTT says to upload its subtitle file again.
Check synchronisation at the beginning, middle and end of the programme. If a caption is already late near the start and remains late throughout, the cue timings may have a consistent offset. If it starts correctly but drifts later, suspect a mismatch between the file and the media version, or a timing process that did not use the same timeline. Adjust against the actual playback, then review again rather than correcting only one visible cue.
This is particularly important for long pre-recorded loops. A cue file timed for one copy of a video does not automatically prove that repeated playback, transitions or pauses in a live presentation will preserve alignment. Check what the live workflow does at each boundary, and verify captions in the destination player if that workflow supports them.
Save as UTF-8 and check special characters
Save the file as plain text with the .srt extension and UTF-8 encoding. Vimeo’s caption documentation recommends UTF-8 for reliable display of special characters. This is useful for names, accented words, punctuation and scripts that may not display correctly under another encoding.
After saving, reopen the file in a text editor and inspect words that use non-English characters. For an Indian devotional programme, that might include a transliterated name or a caption written in a non-Latin script. Look for replacement symbols, question marks in place of letters, or garbled text. If the editor offers an encoding choice, explicitly select UTF-8 when saving rather than assuming it inferred the right one.
Make sure the filename ends in .srt, not a double extension such as .srt.txt. Some editors hide file extensions, so inspect the saved name in the file manager or upload picker. Keep a clean copy of the original text so you can correct a spelling or timing issue without rebuilding the entire track.
Validate and test in your video workflow
Before upload, inspect the file from top to bottom. Confirm that the first cue number is 1; numbers proceed in order; every cue has a start and end time; each timing line uses the expected punctuation and digit widths; each cue has text; and blank lines separate cues. Also check spelling, names, punctuation and any sound descriptions.
Then test the file in the destination workflow, because caption-format support is not identical everywhere. YouTube Studio documents uploading timed subtitle files and also offers transcript auto-sync and manual caption entry. Its guidance lists SubRip (.srt) as a supported format and suggests SRT or SBV for newcomers. You can follow YouTube’s instructions for adding subtitles and captions to choose the video, language and subtitle track, then review the result in Studio.
Vimeo supports SRT and WebVTT for its standard video workflow, but recommends WebVTT for that use. Vimeo OTT documents SRT and VTT workflows of its own. Do not assume that advice for one Vimeo product applies to another, or that an upload accepted for an on-demand video will be ingested into a live encoder session. Consult the relevant Vimeo caption documentation for the workflow you are using.
Preview the captions with the actual video and check the opening, a section around the middle, and the end. Watch for text that appears too early or late, disappears before a phrase finishes, or displays special characters incorrectly. If you replace or recut the media, retest the timing and upload the matching subtitle file again where the platform requires it.
If the file is for a live encoder rather than a video’s subtitle track, confirm the platform’s caption-ingest method with the encoder documentation. These reviewed sources do not establish a universal process that turns a SubRip file into captions on every live simulcast. Keep that uncertainty visible in your workflow instead of assuming that a file beside the video will reach live viewers.
For the broadcast itself, a separate operational problem is keeping a pre-recorded programme running when your own computer is switched off. StreamNeo takes the uploaded video and stream key as the starting point for a continuously running YouTube broadcast, with monitoring and automatic restarts if it drops; that does not change the need to confirm how your caption track is handled.
Choose the workflow that matches the destination
The caption file is only one part of the job. First decide whether you are adding a subtitle track to an uploaded or archived video, or trying to send captions in the live programme itself. Then check the exact platform and product documentation, the accepted file formats, and where the language or track is selected. The distinction prevents wasted time on a file that is correctly written but sent through a workflow that does not accept it.
| Destination or use | What the cited documentation describes | What to check |
|---|---|---|
| YouTube video in Studio | Upload a timed subtitle file, enter captions manually, or use transcript auto-sync; SubRip is listed as supported. | Confirm the intended video, language and subtitle track, then preview the timed file. |
| Vimeo standard video | Supports SRT and WebVTT, while recommending WebVTT for its standard caption workflow. | Check the current workflow and whether SRT is appropriate for that video. |
| Vimeo OTT | Documents SRT and VTT, media-timecode guidance and UTF-8; a replaced video needs its subtitle file uploaded again. | Apply these instructions to Vimeo OTT specifically and recheck after replacing media. |
| Pre-recorded content sent through a live encoder | The cited protocol guidance describes Secure Reliable Transport, not SubRip cue creation. | Confirm separately whether the platform and encoder support caption ingest during the live session. |
If your channel uses recurring programmes or playlists, keep caption files paired with the exact video version they describe. A schedule can help you organise which programme runs when, but it does not keep cue timings correct after an edit. For planning separate feeds, see how to create separate YouTube live streams for different video playlists. For a cloud schedule, the guide to scheduling a YouTube playlist by day and time covers the scheduling question rather than caption authoring.
A file that passes a text check still needs a playback check. This is one reason a small test before committing to a full overnight or recurring broadcast is useful: it can reveal a wrong language track, a timing offset, or a platform mismatch while the correction is still straightforward. If your broader concern is whether a channel will keep running through the night, the practical reliability checklist covers other failure points without changing the caption requirements.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How do I make an SRT file?
Transcribe the final video, divide the text into readable cues, number them from 1, and give each a start and end time in hh:mm:ss,mmm form. Add a text line and a blank separator for each cue, then save as UTF-8 plain text with an .srt extension and test it in the destination workflow.
What timestamp format should I use?
Use two digits each for hours, minutes and seconds, followed by a comma and three digits for milliseconds. For example, 00:00:02,400 --> 00:00:05,200 is an SRT timing line. Check the target platform’s documentation rather than assuming every caption workflow uses the same format.
Why are my captions out of sync?
The file may have been timed against a different edit, or its cues may use a timeline that does not match the media. Compare the start, middle and end with the exact video being presented; if you replace or recut the media, retime or re-upload the matching caption file as required by the platform.
Does SRT mean the streaming protocol here?
Not when the instruction is to prepare a .srt caption file: that means SubRip text. Secure Reliable Transport is a separate protocol for carrying live video. An SRT file does not contain video, and its presence does not guarantee that captions will be sent during a live encoder session.