Subtitle, transcript and timing tools

SRT vs VTT: which subtitle format to use

SubRip (.srt) and WebVTT (.vtt) are the two subtitle formats you will meet on almost every project. Both are plain text, both describe the same basic idea (a block of text tied to a start and end time), and both are readable in a text editor. The differences are in the details, and the details are usually what decide which one a platform wants.

An SRT file is a numbered list of cues. Each cue has a sequence number, a timecode line written as HH:MM:SS,mmm --> HH:MM:SS,mmm (a comma before the milliseconds), the subtitle text, and a blank line before the next cue. There is no file header and no way to attach styling, positioning or metadata: what you see is what you get, which is exactly why SRT is still the format most editing software exports by default and most platforms will accept as an upload.

A WebVTT file opens with a mandatory WEBVTT header line, and its timecodes use a period before the milliseconds instead of a comma (HH:MM:SS.mmm --> HH:MM:SS.mmm). Beyond that, VTT can do things SRT cannot: cue settings for position and alignment, cue identifiers, comment blocks, and CSS-style hooks (::cue) for styling text in a browser. VTT is the format the HTML5 <track> element expects, and it is the format YouTube, Vimeo and most web video players will ask for if you are uploading directly rather than letting a platform burn captions in. If you only have SRT, converting it to VTT is mostly a formatting exercise (swap the header in, swap the commas for periods) rather than a re-timing job, which is why an SRT to VTT converter is a genuinely simple, low-risk tool to reach for.

How subtitle timing works

A subtitle's timing is just two numbers: when it appears and when it disappears, both measured from the start of the video. Everything else, the frame rate of the source footage, the container the video is delivered in, is irrelevant to the subtitle file itself, because SRT and VTT timecodes are written in real time (hours, minutes, seconds and milliseconds), not in frames. That is a deliberate simplification: a subtitle file has to work whether the video plays back at 24, 25 or 30 frames a second, so it is anchored to the clock instead of the frame count.

Good subtitle timing follows a few practical conventions rather than a hard technical rule: a line generally stays on screen long enough to be read at a comfortable pace (roughly the length of the sentence, not a fixed duration), consecutive cues usually leave at least a frame or two of gap so a fast edit does not show two subtitles as one continuous flicker, and a cue should start close to when the speech starts rather than lagging behind it. None of this is enforced by the file format: SRT and VTT will happily accept timing that is uncomfortable to read, which is why subtitle QC is a manual pass even after the timecodes are technically valid.

Where this connects back to timecode maths: if you are hand-adjusting a cue because it starts a beat too early, you are doing the same HH:MM:SS arithmetic a timecode calculator does, just in milliseconds instead of frames. Shifting an entire subtitle file earlier or later (because the edit changed upstream) is the same operation repeated across every cue in the file.

Timecode basics for editors

Timecode is how editing software refers to an exact point in a video: HH:MM:SS:FF, hours, minutes, seconds and a frame number within that second. The frame count in the last field depends on the frame rate: at 25 fps it runs 00 to 24, at 30 fps it runs 00 to 29, and so on. This is different from subtitle timing, which as covered above is measured in milliseconds rather than frames, but the two meet constantly in a real edit: you cut on a frame, then export a subtitle file whose cues need to line up with where you cut.

Two complications come up often enough to be worth knowing before you hit them. The first is drop-frame timecode, used at 29.97 and 59.94 fps, which periodically skips certain frame labels (never actual frames of video) so the displayed timecode keeps pace with a real clock instead of drifting behind it. The second is that 29.97 and 59.94 are not actually 30 and 60: they run at 30000/1001 and 60000/1001 frames per second, a hair under the round number, which matters the moment you convert a frame count to real elapsed seconds. Our timecode calculator above handles both.

In practice this shows up as small, easy-to-miss errors: converting a frame count to real seconds by dividing by 30 instead of 30000/1001 gives a result that runs about 0.1% short over a long programme; a drop-frame and non-drop-frame timeline get mixed and a conform comes out a few frames off. None of it is difficult once you know to look for it, which is really the whole point of keeping a calculator around rather than doing the arithmetic by hand each time.

Estimating speaking time from a script

Before a script is recorded, it helps to know roughly how long the finished audio will run, and word count is the fastest way to estimate it. A commonly used rule of thumb for conversational English speech is somewhere around 130 to 160 words per minute; slower, more deliberate narration (the kind used for a documentary voiceover or an explainer) tends to sit closer to 110 to 130 words per minute. These are estimates, not measurements: an individual speaker's pace, the amount of pausing for emphasis, and how much of the script is dialogue versus narration will all move the real number in either direction.

The practical use of this is sizing a script before you record it, not replacing a stopwatch afterwards. If a script comes in at 900 words and you are working to a rough figure of 150 words per minute, that is roughly six minutes of finished audio before edits and pauses are accounted for, useful for checking a script against a target runtime, or for working out how many words you have room for in a 60-second ad. Once the actual recording exists, its real duration is the number that matters, and the estimate has done its job.

Estimating speaking time is a separate exercise from subtitle timing. A word-count estimate tells you roughly how long a script will take to read aloud, in the abstract, before anything is recorded; subtitle cues are timed against an actual recording, cue by cue, once the words and the performance both exist. It is worth keeping the two apart: a script that reads as five minutes on paper can come out shorter or longer once a real speaker performs it.

Planning file size and bitrate

A video file's size is, at its simplest, bitrate multiplied by duration: a higher bitrate means more data is stored for every second of video, and a longer video means more seconds to multiply by. Resolution and frame rate push in the same direction indirectly, because more pixels and more frames per second generally need a higher bitrate to encode cleanly at the same visual quality, but it is the bitrate figure itself, not the resolution number, that determines the file size for a given duration.

The codec matters as much as the bitrate. A newer, more efficient codec can deliver comparable visual quality at a meaningfully lower bitrate than an older one, which is why two files of the same resolution and duration can differ substantially in size depending on how they were encoded. This is also why a bitrate figure alone does not tell you what a platform requires: a delivery spec usually names both a codec and a bitrate (or a bitrate range) together, because the two are only meaningful as a pair.

Working backwards from a target file size (a platform's upload limit, an email attachment cap, a fixed budget for hosting storage) is the same formula run in reverse: divide the size budget by the duration to get an available bitrate, then choose settings that fit inside it. It is worth checking a platform's own current upload specification before exporting to a hard limit, since these figures are set by the platform and do change.

Adding chapters to YouTube videos

YouTube chapters split a video into a set of user-selectable sections, shown as markers on the timeline and as a list under the video, generated from timestamps you add to the video description. There is no separate chapters file to upload: the timestamps live directly in the description text, one per line, each followed by the label for that section.

YouTube's own help documentation sets specific rules for when a set of timestamps is recognised as chapters, rather than just being plain text in the description: the first timestamp must be 0:00, the timestamps must be listed in ascending order, you need at least three timestamps in total, and each individual chapter must run at least 10 seconds. A description that breaks any of these (starts its first chapter later than 0:00, lists times out of order, or has fewer than three markers) will not be turned into chapters, even though the text is still visible in the description. (Verified against support.google.com/youtube/answer/9884579, 22 September 2026.)

Chapters are worth adding to anything with distinct sections, an interview with several topics, a tutorial with steps, a long-form conversation with tangents, because they let a viewer jump straight to the part they want rather than scrubbing the timeline blind. Titling each chapter with a short, specific description of what happens there (rather than a generic label) is what actually makes that navigation useful once it exists.

Questions about subtitles, transcripts and timing

Should I deliver SRT or VTT?

Check what the platform or player asks for: SRT is the safer default for a general upload or for sending to another editor, while VTT is what web video players and the HTML5 track element expect, and what most platforms want if you are attaching styling or positioning. When in doubt, SRT is simpler and near-universally accepted.

Do subtitle files use timecode or timestamps?

Subtitle cues in SRT and VTT are timed in hours, minutes, seconds and milliseconds, not in frames, so they are not timecode in the SMPTE HH:MM:SS:FF sense used inside editing software. That keeps a subtitle file valid regardless of what frame rate the video plays back at.

How accurate is a words-per-minute estimate for voiceover?

It is a rough planning figure, not a measurement: real speaking pace varies by speaker, by how much of the script is pausing versus talking, and by whether it is narration or dialogue. Use it to size a script before recording, then treat the actual recorded duration as the figure that matters once it exists.

Why did my YouTube timestamps not turn into chapters?

The most common reasons are the first timestamp not starting at 0:00, the timestamps not being in strict ascending order, having fewer than three timestamps listed, or a chapter running under YouTube's 10-second minimum. Fixing whichever of those applies and re-saving the description is usually enough.