Subtitle viewer: read every cue, shift or re-time them, save

What it shows and fixes

• Every cue. Number, start, end, duration and text, with a search box that narrows the table as you type. The summary gives the cue count, when the first cue starts, when the last one ends, and the span between them.
• Problems. Overlapping cues (one starts while another is still on screen, so players stack them), zero and negative durations (never shown, or shown for a frame), cues out of order (some TVs and older players stop showing subtitles after a cue that goes back in time), and lines over 42 characters. Tap a cue number in the list to jump to it.
• Shift. Move every cue earlier or later by the same amount, typed in milliseconds (-1500) or seconds (-1.5 s). A cue that would start before 0:00 is held at 0 and counted.
• Re-time from two sync points. Say when an early cue and a late cue should really start; every cue is moved along the straight line through those two points. That fixes an offset and a steady drift at once. A frame-rate helper fills in the two times for the common mismatches.
• Save. As SubRip (.srt) or WebVTT (.vtt), in UTF-8, optionally with a byte-order mark for older TVs and players. Sort by start time when cues are out of order; undo everything with one button.
• Watch with a video. Choose a video file on your device and it plays right here with the cues on it, updated as you shift or re-time them. The browser plays it from a local blob: address; it is not uploaded.

Why subtitles drift, and the two-point fix: a worked example

A film shot at 23.976 frames per second is sped up to 25 fps for PAL television and many European DVDs, so it runs 4.27% faster (25 / 23.976 = 1.042709) and a two-hour film ends almost five minutes sooner. Subtitles timed to that release come up earlier and earlier on a 23.976 fps copy: 2.6 seconds early after one minute, and 3 minutes 50.6 seconds early by the 1:30:00 mark. No single shift can fix that.

Two sync points can. If cue 1 is at 00:00:10,000 and should be at 00:00:10,427, and the last cue is at 01:40:00,000 and should be at 01:44:16,256, every time t becomes 10,427 + (t − 10,000) × (6,256,256 − 10,427) / (6,000,000 − 10,000) milliseconds. A line at 01:30:00,000 lands at 01:33:50,630, within a millisecond of 5,400,000 × 25 / 23.976. Choosing made for 25 fps, video is 23.976 fps and pressing Fill in the two times does that arithmetic for you; typing times you read off the video works for any drift, frame-rate or not.

Files it opens

.srt (SubRip)

A number, a time line such as 00:01:02,500 --> 00:01:04,000 with a comma before the milliseconds, the text, and a blank line. Sloppy real files are read too: missing numbers, a dot instead of the comma, one-digit hours, a missing blank line between cues. SubRip X1/Y1 position coordinates are noted and dropped.

.vtt (WebVTT)

The W3C format that the HTML <track> element plays, which is why web video needs .vtt rather than .srt. It starts with WEBVTT, uses a dot before the milliseconds, and can carry cue settings (line:, position:, align:, size:, vertical:), STYLE and REGION blocks and NOTE comments. Settings and STYLE/REGION blocks are kept when you save as .vtt; NOTE comments are counted but not written back.

.ass and .ssa (SubStation Alpha)

The styled format from Aegisub and anime fansubs. The Dialogue: lines of the [Events] section are read by their Format: line, with commas inside the text kept, \N read as a new line and override codes such as {\i1} removed. Only the text and times are used: fonts, colours, positions and karaoke effects are not drawn, and are not carried into the saved .srt or .vtt.

Text encodings

UTF-8 (with or without a byte-order mark) and UTF-16 (with a byte-order mark, or recognised by its zero bytes) are detected. Anything that is not valid UTF-8 is read as Windows-1252, the usual encoding of older Western European .srt files, and the page says so. Saved files are always UTF-8.

Useful to know

SRT or VTT?

Desktop players (VLC, mpv, MPC-HC), most TVs and YouTube take .srt. Browsers only play WebVTT in a <track>, and HLS streaming uses WebVTT too. Converting SRT to VTT and back keeps every time and every word; what can be lost is formatting one side has and the other lacks (VTT voice and class tags, SRT <font> colours).

Why 42 characters?

It is a common guideline, not part of either format: Netflix's timed-text style guide sets 42 characters per line for most Latin-script languages, with at most two lines. Broadcasters using teletext-style captions often keep to about 37. The limit here can be changed.

Subtitles on a TV from a USB stick

Most TVs load an .srt that has exactly the video's file name (Film.mkv and Film.srt) from the same folder. If accents come out as odd symbols, save it here with the byte-order mark ticked.

What this cannot do

• Sync to the audio by itself. There is no speech detection: you give the times (or the frame rates), and it does the arithmetic. Tools such as ffsubsync or Subtitle Edit's audio sync listen to the soundtrack.
• Translate. The text is shown and saved exactly as it is.
• Read or remove burned-in subtitles. Text drawn into the video picture is pixels, not a subtitle file. Nor does it extract subtitle tracks from inside an .mkv or .mp4; the video and audio viewer lists them, and MKVToolNix or ffmpeg can extract them.
• Edit the text. Only times change here: shift, re-time, sort. Subtitle Edit or Aegisub edit the words.
• Read other subtitle formats. MicroDVD .sub (frame numbers), VobSub .sub/.idx and Blu-ray .sup (pictures of text), TTML/DFXP and SAMI .smi are not read. A file in a code page other than UTF-8, UTF-16 or Windows-1252 (Cyrillic Windows-1251, Chinese GBK) opens with garbled letters.
• Play every video. The preview uses the browser's own player: MP4 (H.264), WebM and most MOV files play; MKV often plays in Chrome and Edge when its codecs are ones the browser has; HEVC and AC-3 sound often do not.