SRT ↔ WebVTT Subtitle Converter

Features

• SRT ↔ WebVTT both ways, with the input format detected
• Shift the whole timeline (seconds, may be negative) — fixes audio desync
• Scale the timeline — fixes frame-rate mismatch, which drifts further out the longer the file runs and cannot be fixed by shifting
• When both apply, scale first and then shift (the other order scales the offset too)
• ⚠️ A shift that would produce negative times is refused with a count, instead of writing a broken file
• SRT cue numbers are renumbered in order — they carry no data and the input’s may be scrambled
• WebVTT output omits numbers but keeps existing cue identifiers and cue settings
• Understands WebVTT’s hour-less form (`00:01.000` is one second, not one hour)
• Handles CRLF, BOM, and NOTE / STYLE comment blocks
• Nothing is uploaded and no server is involved

How to use

1. Paste SRT or WebVTT — the format is detected for you
2. Pick the output format
3. For desync, enter a shift in seconds; for a frame-rate mismatch, enter a scale factor
4. The result updates as you type — copy or download it

FAQ

My subtitles are out of sync — shift or scale?

Look at the pattern. A constant offset from start to finish means shift: enter a fixed number of seconds (negative if the subtitles appear too early, positive if too late). Correct at the start but drifting further out means scale, which is a frame-rate mismatch: subtitles authored for 23.976 fps played on a 25 fps release need 25 ÷ 23.976 ≈ 1.0427, and the reverse case needs 23.976 ÷ 25 ≈ 0.959. ⚠️ Both problems often occur together (a different release *and* a different subtitle source), in which case fill in both — and the order is scale first, then shift, because the other way round scales the offset you just added.

Why does too large a shift error out when other tools just clamp it?

Because clamping quietly breaks the file. Shifting five seconds earlier makes the first cues negative: clamping them to zero makes them all display at once, and writing them as-is produces illegal timestamps like `-00:00:01,000`. A player reports neither — those cues simply stop appearing, and you conclude that is just how the subtitles are, when in fact the tool mangled them. So this refuses and tells you how many cues are out of range: reduce the shift, or delete the leading cues you genuinely do not want.

Do the SRT numbers change?

Yes — the output renumbers them 1, 2, 3… in order. SRT numbers carry no information; they only mean “this is the nth cue”, and the input file’s may be scrambled or have gaps (common after copy-paste or hand editing), which makes a few players show nothing beyond the first few entries. WebVTT output writes no numbers: that slot holds a cue identifier (any string), and putting `1`, `2`, `3` there is legal but invites the belief that it works like SRT numbering. Existing identifiers are preserved.

Does it support ASS / SSA?

No. ASS / SSA is not just “text with timestamps” — it carries a full styling system (fonts, outlines, positioning, karaoke effects, layers), and neither SRT nor WebVTT has anywhere to put those. A one-way conversion would necessarily drop most of the styling, and the result *looks* like a successful conversion while the positioning and fonts are wrong in the player — something you discover while watching. So this covers only the two formats that convert losslessly into each other.