Subtitle timing
SRT timecode format (HH:MM:SS,mmm)
Last updated: 2026-06-11
An SRT timecode is written HH:MM:SS,mmm — two-digit hours, minutes, and seconds, a comma, then exactly three millisecond digits, as in 00:01:14,500. Each cue joins its start and end times with a space-arrow-space: 00:01:14,500 --> 00:01:17,000. The comma before the milliseconds is mandatory (WebVTT uses a dot), cues run in order without overlapping, and the cue text sits on the line below the timing line.
This is the strictest part of an SRT file. Getting the comma, the three-digit milliseconds, and the arrow exactly right is what keeps a file parseable across players. This page complements the broader subtitle timecodes guide.
The syntax piece by piece
Each field has a fixed width and separator. The table breaks the timecode into its parts.
| Field | Width | Separator | Example |
|---|---|---|---|
| Hours | 2 digits | : | 00 |
| Minutes | 2 digits | : | 01 |
| Seconds | 2 digits | , comma | 14 |
| Milliseconds | 3 digits | space --> space | 500 |
| Full line | — | — | 00:01:14,500 --> 00:01:17,000 |
Where the timecode sits in a cue
An SRT cue is three parts: an integer index, the timing line, then one or more text lines, followed by a blank line before the next cue. The timecode is always the second line of the block. A two-cue example:
1 00:01:14,500 --> 00:01:17,000 Where are we going? 2 00:01:17,200 --> 00:01:19,800 Nowhere. Get back inside.
Note cue 2 starts (17,200) after cue 1 ends (17,000) — a small positive gap, which is correct.
Ordering and gap rules
Cues must be listed in chronological order and numbered sequentially from 1. Within a cue, the end time must be later than the start time, giving a positive duration. Between cues, the next start time should be at or after the previous end time, leaving a non-negative gap. A tiny gap (a few frames) between consecutive cues is normal and helps the eye register the change. Players differ in how strictly they enforce these rules, but a file that follows them works everywhere.
Common timecode errors
Most broken SRT files fail on a handful of timing mistakes. The table lists the frequent ones and what they look like.
| Error | Bad | Correct |
|---|---|---|
| Dot instead of comma | 00:01:14.500 | 00:01:14,500 |
| Too few ms digits | 00:01:14,5 | 00:01:14,500 |
| Wrong arrow | 00:01:14,500 -> … | 00:01:14,500 --> … |
| Negative duration | 17,000 --> 14,500 | 14,500 --> 17,000 |
| Overlap (negative gap) | cue 2 starts before cue 1 ends | cue 2 starts at/after cue 1 ends |
Timecodes and translation
Because the timecode controls when each line appears, a translation must leave it untouched. Changing even one comma, dropping a millisecond digit, or shifting a start time desyncs the line from the audio. The SubLingo translator parses the cues and rewrites only the text, so every HH:MM:SS,mmm value and the --> arrow stay byte-for-byte identical (see how to translate an SRT file). For the full file layout around these timecodes, read the SRT file format.
Key facts
- Format: HH:MM:SS,mmm — comma, then exactly three ms digits.
- Start and end joined by space-arrow-space: -->.
- Comma is required; a dot is WebVTT and invalid in strict SRT.
- Cues are ordered, numbered from 1, and should not overlap.
- End time must be after start time (positive duration).
- Translation keeps every timecode and arrow byte-for-byte identical.
Definitions
- HH:MM:SS,mmm
- The SRT timecode: 2-digit hours, minutes, seconds, a comma, then 3 millisecond digits.
- Comma separator
- The required punctuation before milliseconds in SRT (
,500). WebVTT uses a dot. - --> arrow
- Two hyphens and
>with a space each side, joining start and end time. - Cue index
- The sequential integer on the line above the timecode, starting at 1.
- Overlap
- A cue that starts before the previous one ends; out of spec and a common error.
- Negative duration
- A cue whose end time precedes its start time; invalid and must be fixed.
Related guides
FAQ
What is the SRT timecode format?+
An SRT timecode is HH:MM:SS,mmm — two-digit hours, minutes, and seconds, then a comma, then exactly three millisecond digits, for example 00:01:14,500. Each cue has a start and end time joined by a space-arrow-space: 00:01:14,500 --> 00:01:17,000.
Why does SRT use a comma before the milliseconds?+
SRT (SubRip) was authored in a locale that uses the comma as the decimal separator, so the format fixed the comma into its spec. WebVTT later chose a dot. The comma is required in SRT; a dot there makes the timecode invalid in strict parsers.
What does the --> arrow mean in an SRT file?+
The arrow separates the start time from the end time on a cue's timing line. It is two hyphens and a greater-than sign with a single space on each side: 00:01:14,500 --> 00:01:17,000. The cue text follows on the next line.
Do milliseconds have to be three digits?+
Yes. SRT milliseconds are always three digits, zero-padded — 00:00:01,050 not 00:00:01,5. Dropping digits or using one or two breaks parsing in strict players, even though some lenient ones tolerate it.
Can SRT cues overlap in time?+
The SRT spec expects cues in order with non-overlapping times, so one cue ends before the next begins. Some players show overlapping cues stacked, but overlaps and out-of-order cues are a common error that causes flicker or missing lines.
What is a negative gap or negative duration?+
A negative duration is when a cue's end time is earlier than its start time, which is invalid. A negative gap is when a cue starts before the previous one ended (an overlap). Both come from bad editing and should be corrected.
Will translation change SRT timecodes?+
It should not. A correct subtitle translation changes only the cue text and leaves every HH:MM:SS,mmm timecode and the --> arrow byte-for-byte identical. SubLingo preserves the timing exactly, so the translated file stays in sync.