Shift subtitle timing online

Shift subtitle timing by one exact offset

A subtitle file can be perfectly written and still feel wrong because every line appears a little too early or late. That is a constant-offset problem. If a spoken word begins at 00:01:05.500 in the video while its subtitle begins at 00:01:03.000, the file needs a positive 2,500 millisecond shift. Every cue start and end moves later by that same amount. A negative number moves every cue earlier. The arithmetic is printed before the result is offered, so “plus” never relies on an ambiguous early-versus-late label.

Milliseconds are the source of truth. Quick buttons can fill the field with common values, but they are shortcuts rather than a limit. The preview shows the timestamps before and after the operation, including cues near the beginning and end of the file. Cue text stays visible beside those times, which makes a reversed sign or a misplaced decimal much easier to catch than it would be after a blind download.

Use two anchors when the error grows steadily

A fixed shift cannot repair a subtitle that is close at the beginning and several seconds wrong near the end. That pattern often comes from two editions with slightly different running times or from a steady time-scale mismatch. Correct steady drift asks for two subtitle times and the two moments where those lines actually belong in the video. One affine mapping then moves and scales the complete subtitle timeline.

The two subtitle anchors must increase, and the two matching video anchors must increase. The first anchor establishes the offset; the distance between both pairs establishes the scale. Every cue boundary uses that same mapping before, between and after the anchors, then rounds to the nearest integer millisecond with a stated rule. There is no hidden 23.976-to-25 FPS preset and no claim that the browser detected a frame rate from a subtitle text file. If the mismatch changes abruptly after an inserted scene or advertisement, one steady map is the wrong model and the preview should expose that limitation rather than conceal it.

Negative subtitle times require an explicit decision

Moving subtitles earlier can push the first cue across 00:00:00.000. By default, that blocks the result. Silently changing a requested offset, clamping several cues to zero, or deleting dialogue would all produce a different file from the one requested. The error names the boundary so the offset or anchors can be corrected.

Trim at zero is the deliberate alternative. A cue whose shifted end is at or before zero is removed because none of its display interval remains. A cue that begins before zero but ends after it is kept with its start clamped to zero. Removed and clamped counts appear in both preview and receipt. Overlapping cues remain overlapping; the tool does not sort, merge, deduplicate or renumber them in an attempt to make the file look tidier.

SRT and WebVTT carry more than visible dialogue

SubRip uses comma-separated milliseconds in timing lines and commonly places an index before every cue. WebVTT uses a decimal point and can carry cue identifiers, positioning settings, comments, regions and style blocks. Text inside a cue can itself look like a timestamp or an arrow. A safe subtitle shifter distinguishes those structures instead of running one regular expression across the complete document.

The output stays in the input format. Accepted file input keeps its encoding marker and newline contract, while accepted cue text, order, identifiers, settings and metadata blocks remain in place. Pasting is also supported because subtitle source often lives in a text editor or message. A browser textarea creates new UTF-8 text with normalized line endings, so the receipt identifies it as pasted source rather than pretending it preserved file bytes that were never supplied.

Malformed timing does not pass through as an unchanged “invalid block.” Invalid encoding, missing cues, reversed ranges, malformed timestamp components and unsupported content stop output with a specific error. A zero offset or two anchors that describe the identity map is a no-op, not a successful download. Fixing a recipe and running it again reuses the submitted source, while any older preview and object URL disappear immediately.

The receipt is built from verified output bytes

The result is parsed again before download is enabled. The worker checks the expected cue count, transformed timestamps, format and preservation scope against the actual output. The receipt reports input and output bytes, cues read and written, any explicit removals or clamps, the exact offset or anchor scale, and the earliest and latest times before and after. A worker failure or canceled operation cannot leave an old receipt beside newer settings.

There is no fixed file-size rejection. Large subtitle documents receive the shared memory advice and remain runnable. Work occurs away from the main interface, progress follows real phases or cue work rather than a timer, and Cancel terminates the active generation. The full output remains available for download while the on-page preview stays bounded and paginated, preventing one unusually large subtitle file from becoming one enormous DOM tree.

No upload, transcription or video rewrite

The subtitle file is decoded, transformed and verified in this tab. No subtitle text, filename, cue timing or output byte is posted to a server. The same-origin worker code can be fetched only after source is supplied; that request is identical for every visitor and does not contain the submitted material.

This page does not listen to video, recognize speech, create captions, translate dialogue, edit cue wording, convert a subtitle into another format, or burn text into picture frames. Automatic audio alignment needs media decoding, language and confidence contracts that a deterministic file shifter does not have. Embedding subtitles into MP4 also requires a media muxing result rather than a corrected subtitle file. Keeping those jobs outside this route is what makes its preview and receipt precise enough to trust.