Subtitle Time Shift

How it works

Offset input is a decimal count of seconds with an optional plus or minus sign and at most three decimal places. It is converted to an integer millisecond count by splitting the whole and fractional digits, not by repeatedly adding floating-point seconds to each cue. Every cue receives the same integer adjustment at both boundaries, so durations and gaps are unchanged. A zero offset is allowed when you want to inspect and normalize a supported file without moving the timing.

A negative timestamp cannot be represented by the supported SRT or WebVTT shapes. If even one shifted cue begins before zero, the entire operation is refused with its source line. The tool does not clamp a cue to zero, delete early captions, shorten a duration or offer a partial file. A later end beyond 9,999:59:59.999 also stops export. Choose a different offset or make a separate deliberate editorial decision in your subtitle editor.

SRT input uses positive numeric cue counters and hours:minutes:seconds,milliseconds timestamps. The numeric identifiers, cue text and original cue order remain in a same-format shifted file. WebVTT supports a bare WEBVTT header or one header-comment line, optional cue identifiers, NOTE blocks and recognized basic cue settings. These are preserved in the shifted output. Recognized settings are vertical, align, size, position and line, with bounded values and no duplicated key. STYLE, REGION, region settings and additional header metadata are rejected rather than guessed or dropped.

WebVTT inline timestamp tags carry timing inside the cue payload, not only at its start and end. Those files are refused because changing only cue boundaries could leave the inner timestamps inconsistent. Ordinary cue markup without embedded timestamps is kept as supplied; this is a timing transform, not a full WebVTT payload-conformance or rendering validator. Markup is displayed as text in the preview and is never injected into the page.

Cue start times must be non-decreasing and every end must be later than the start. Intentional overlapping captions remain overlapping after a constant shift, and a notice makes that visible. The tool never sorts or repairs source order. Multi-line payloads remain multi-line, with a blank source line acting as the cue separator. Unknown SRT positioning extensions and ambiguous arrows inside a cue are refused. SRT has informal variants rather than one comprehensive standard, so a valid file for another application can be outside this explicitly supported shape.

UTF-8 input is limited to 2 MiB, 10,000 cues and 60,000 lines. An initial BOM is accepted and omitted with a notice. Output normalizes CR or CRLF to LF and writes hours explicitly. These normalizations mean the file is not byte-for-byte identical even when the offset is zero. The result preview shows only the first 20 cues; the downloaded SRT or VTT includes all accepted cues.

All work stays in browser memory and no audio, video, subtitle service or URL is contacted. Changing the offset, format or text clears the previous result before another export. A delayed file read is discarded after a newer edit or cancellation. A downloaded subtitle can contain private names and conversations, so review it before sharing. Clear affects the widget, not copies already on your device. Always check the output against your actual media: consistent arithmetic does not establish that the chosen offset was correct.

Common use cases

• Compensate for a known opening-intro difference between two video cuts
• Move captions earlier when every line lags dialogue by the same amount
• Keep WebVTT notes and basic cue positioning during a supported timing change
• Review a proposed negative offset before it would remove early caption time

Frequently asked questions

Standards and limitations

• W3C: WebVTT cue timing, overlap, identifiers and settings
• Library of Congress: SRT timestamps and informal variants
• HappyScribe: fixed subtitle offset workflow