Subtitle fixer & converter

Shift, resync, repair and convert SRT and WebVTT.

Paste or drop an SRT or WebVTT file. See what’s wrong with it, shift it, pull a drifting file back into sync from two lines you know, trim overlaps, fix gaps, snap to frames and convert between SRT and WebVTT. Every change is shown before it’s applied and can be undone, and before you download you see exactly what the other format can’t hold. TTML, IMSC, EBU-TT-D, EBU-STL and SCC can all be fixed and written back too. It all runs in your browser: nothing is uploaded or kept.

Nothing is corrected behind your back

A cue whose timing can’t be read, like a 61st second or SRT commas in a WebVTT file, is listed with its line number and kept exactly as written, never guessed at or dropped. Cleanups that can’t change what a viewer sees (sorting, renumbering, tidy timestamps, removing exact duplicates) are one click each. Timing fixes are proposed cue by cue for you to tick. Anything that changes the words, such as merging, splitting, re-breaking or shortening, is only ever a suggestion.

Your own profiles

Set the limits a client asks for (durations, gaps in frames, lines, characters per line, reading speed) and save the profile under its name. Presets keep a whole setup (frame rate, profile, output format) in this browser, and the page’s link carries the same settings, so a colleague opens it ready to go. Settings only: your subtitles are never saved or put in a link.

Timing around shot changes

Load the cuts as an EDL, an ffmpeg scene-detection log or a list of timecodes, and see every cue against them. The tool suggests the usual fixes: start on the cut when dialogue starts within half a second of it, and end two frames before a cut rather than just across it, following Netflix’s timing guidelines. Each suggestion is yours to tick or leave; none is made if it would crowd the next cue.

A whole series at once

Choose several files and they’re all fixed and converted with the same settings: the cleanups you tick, a shift if you need one, and, only if you ask, every profile timing fix accepted without the cue-by-cue review. You get one zip with the fixed files and an audit report that lists, file by file, every change made and everything left behind.

Drift: when a shift isn’t enough

If the first line is right but the last is seconds out, the file is running at the wrong speed, usually because it was timed to a different frame rate. Give the tool one line near the start and one near the end, where each is and where it should be. It works out the offset and stretch exactly, shows them in parts per million, and says when the stretch matches a known frame-rate change (25/24 PAL speed-up, or 1000/1001), before anything is applied.

Frame rates, exactly

23.976, 29.97 and 59.94 are held as 24000/1001, 30000/1001 and 60000/1001, so shifting by a frame a thousand times and back lands on the same millisecond. When the frame rate changes, the tool asks whether the running time changed (the same frames playing faster, as in PAL speed-up) or not (pulldown, standards conversion). A subtitle file can’t tell you which.

What SRT and WebVTT can hold

Both store times to the millisecond. WebVTT adds cue identifiers, position and alignment settings, voice and class tags, regions, styles and NOTE comments; SRT has only italics, bold, underline and font colour. Converting WebVTT to SRT lists every setting, tag and note that won’t survive before you download.

TTML, IMSC and EBU-TT-D

A TTML file fixed and saved as the same flavour keeps everything it had: styles, regions, metadata, even namespaces the tool knows nothing about. Only the timing of cues you moved changes. Written from SRT or WebVTT, each flavour gets a clean document with italics, bold and underline as styles, and EBU-TT-D output is checked against the EBU’s own schema. Times are exact where the format allows: frame times at 29.97 are written as frames in TTML and IMSC, and EBU-TT-D, which has no frames, lists any it has to round.

SCC: written the way an encoder sends it

An SCC file is a stream of CEA-608 commands, two bytes per frame at 29.97. Each caption is loaded into the decoder’s hidden memory in the frames before it’s due, shown on its exact start frame and cleared on its end frame, with every control code sent twice as broadcast practice expects. Lines are centred at the bottom, italics and underline come across, and anything 608 can’t do (bold, colour, a character outside its tables, more than four rows) is listed first. A caption too close to the one before to load in time starts late, and the list says by how many frames.

EBU-STL

EBU-STL is written as the binary file broadcasters ingest: a full GSI header, a TTI block per subtitle with extension blocks for long text, accents in its own ISO 6937 character table, italics and underline as STL codes, and either open subtitles or Teletext level 1 with double-height boxed rows. STL only knows 25 and 30 frames a second: 29.97 is written as STL30.01, which is how broadcast tools read it, and anything that has to move to fit is listed first.

EBU-STL and SCC as sources

These formats carry more than the others can: teletext colours, boxing and position in EBU-STL; and in SCC, a stream of CEA-608 commands with rows, colours, roll-up and a second channel. The tool reads the text and exact timing (italics and underline come across), and lists everything else it leaves behind before you save. EBU-STL text is decoded with its own ISO 6937 character table, so accents arrive as written.

Sources: W3C WebVTT; for the shot-change suggestions, Netflix Timed Text Style Guide (Subtitle Timing Guidelines), used as editing advice only.