Subtitle Converter
Subtitle Converter translates subtitle files between SRT, VTT and SBV without uploading anything. It detects the input format automatically, converts timing to the millisecond, shifts every cue earlier or later by any number of seconds, and flags overlaps, empty cues and broken timestamps before you download.
Subtitle input
Everything runs in your browser — subtitle files never leave your device.
SRT vs VTT vs SBV: which subtitle format do you need?
Subtitles look simple — text with timestamps — but three competing formats divide the ecosystem, and picking the wrong one means captions that silently refuse to load. SRT (SubRip) is the lingua franca: virtually every desktop player (VLC, MPV, MPC-HC), editor (Premiere, DaVinci Resolve, Aegisub) and archive reads it. Its grammar is minimal: a running cue number, a timing line HH:MM:SS,mmm --> HH:MM:SS,mmm with a comma separating milliseconds, then one or more text lines, then a blank line. The cue numbers carry no meaning beyond ordering, which is why converters renumber them freely.
VTT (WebVTT) is the only format browsers understand natively. An HTML5<video> element renders captions from a<track kind="subtitles"> element only if the file begins with the literal WEBVTT header and uses period milliseconds (00:00:01.000). VTT additionally supports cue identifiers (an optional line above the timing), NOTE comments, and STYLE/REGIONblocks for positioning and styling — metadata this converter skips rather than mistranslates, and reports as a warning so nothing is silently lost.
SBV (SubViewer) is YouTube's upload format: no cue numbers, no arrows, just 0:00:01.000,0:00:04.000 — two dot-millisecond timestamps separated by a comma, with unpadded hours. Converting between the three is conceptually a timestamp rewrite plus structural normalization, but the edge cases are where naive converters corrupt files: SRT allows cue settings after the end timestamp (00:00:01,000 --> 00:00:04,000 X1:00 X2:00), VTT allowsMM:SS.mmm without hours, and real-world files mix line endings and carry byte-order marks. This tool normalizes all of that on parse.
How auto-detection works
Detection runs before parsing and never throws. A leading WEBVTT token means VTT. Otherwise the engine looks for SBV's signature — a line shaped likeH:MM:SS.mmm,H:MM:SS.mmm with no arrow — then SRT's comma-millisecond arrows, then VTT's dot-millisecond arrows. Anything else is reported as unknown rather than guessed, because mis-parsing a transcript as subtitles produces confidently wrong output.
Retiming: fixing constant-offset drift
The most common subtitle defect is not a wrong format but a wrong clock: subtitles ripped from a theatrical cut applied to a director's cut, or captions authored against a 23.976 fps master played at 25 fps, drift by a near-constant offset. Shifting every cue by ±N seconds fixes the constant component instantly. The engine applies the delta in integer milliseconds (rounding once, at the end), clamps starts at zero, and drops cues that would end at or before zero — a cue occupying negative time can never be displayed, so keeping it would only confuse players. Shifts compose, so coarse-then-fine adjustment (first +2 s, then −0.15 s) converges quickly.
What the timing check validates
Players are lenient in different ways, which makes broken files failinconsistently — fine in VLC, flashing in Chrome, rejected by YouTube's uploader. The validator checks the four defects with real consequences:
- Overlaps: a cue starting before its predecessor ends. Browsers stack both texts; some smart TVs flicker.
- Empty cues: timing with whitespace-only text, which renders as a visible blank caption box.
- Non-positive duration: end at or before start. Most parsers drop the cue without warning, silently deleting dialogue.
- Out-of-order cues: a cue starting before the previous cue started — the signature of a bad concatenation or a rip that mixed two subtitle tracks.
Issues are reported per cue number against the shifted timeline, so you validate exactly what you will download.
Privacy and encoding notes
Subtitle work frequently involves pre-release screeners, client cuts under NDA, or internal training video. Everything here — detection, parsing, conversion, shifting, validation — executes in the page's JavaScript context; the Network tab will confirm no request carries your text. On encoding: author and save subtitles as UTF-8. The WebVTT specification mandates UTF-8, and while SRT has no formal spec, every modern tool assumes it. Legacy Windows-1252 SRT files (common in old fansub archives) will show mojibake for accented characters; re-save as UTF-8 before converting.
Frame rates, drop-frame timecode and drift that shifting cannot fix
A constant offset is the easy case. Harder drift comes from frame-rate mismatches: a subtitle file authored against a 23.976 fps master but played against a 25 fps encode gains roughly 4% error progressively — one second late after 25 seconds, a full minute late after 25 minutes. No single shift fixes progressive drift; the correct repair is a linear rescale of every timestamp (multiply by 23.976/25), ideally anchored at two sync points. Broadcast drop-frame timecode adds another wrinkle: NTSC's 29.97 fps means timecode numbers periodically skip to stay aligned with wall-clock time, so a naive frame-count-to-milliseconds conversion lands several seconds off over an hour. When dialogue starts in sync and visibly slides as the video plays, measure the offset at the beginning and at the end — if the two offsets differ, you need rescaling, not shifting. Convert the format here first (so every timestamp is normalized), then apply the rescale in your editor of choice.
Which keyboard shortcuts does the subtitle converter support?
Frequently asked questions
What is the difference between SRT, VTT and SBV subtitle formats?
SRT (SubRip) is the universal interchange format: numbered cues with timestamps like 00:00:01,000 --> 00:00:04,000 using a comma for milliseconds. VTT (WebVTT) is the web-native format required by HTML5 <video> tracks and most browsers; it starts with a WEBVTT header, uses a period for milliseconds (00:00:01.000), supports cue identifiers, and allows NOTE, STYLE and REGION metadata blocks. SBV (SubViewer, YouTube's format) drops cue numbers and arrows entirely, using comma-separated timestamps like 0:00:01.000,0:00:04.000. This converter translates losslessly between all three, preserving cue text and timing to the millisecond.
How do I convert SRT to VTT for HTML5 video?
Paste your SRT content (or upload the .srt file), confirm the auto-detected SRT badge, select VTT as the target format, and click Download. The output includes the mandatory WEBVTT header, converts every timestamp from comma to dot milliseconds, and renumbers nothing (VTT cue identifiers are optional). Reference the file from a <track kind="subtitles" src="captions.vtt" srclang="en"> element and browsers will render it natively — no JavaScript player required.
How does the time shift (retiming) feature work?
Enter a positive or negative number of seconds — decimals like 1.5 or -0.25 are supported — and click Apply shift. Every cue's start and end time moves by that offset. Shifts are cumulative, so you can nudge repeatedly until the dialogue lines up. Start times clamp at zero (a cue can never begin before the video starts), and any cue that would end at or before zero is dropped with the remaining cues renumbered. This fixes the classic problem of subtitles ripped from a different cut of a video running a constant offset early or late.
What subtitle problems does the timing check catch?
Four classes of defects that break players or confuse viewers: overlapping cues (a cue starts before the previous one ends, causing flicker or stacked text), empty cues (timing with no text, which flashes a blank box), non-positive durations (end time at or before start time, which most parsers silently drop), and out-of-order cues (a cue that starts before the previous cue started, indicating a bad rip or merge). Each issue is listed with its cue number so you can fix the source file.
Will my subtitle files be uploaded anywhere?
No. Parsing, conversion, retiming and validation all run locally in your browser using plain JavaScript — there is no server endpoint that receives subtitle content. This matters because subtitle files often accompany unreleased video, screener copies, or client work under NDA. You can verify the claim in your browser's developer tools: the Network tab shows zero requests carrying your text.
Which character encoding should my subtitle files use?
UTF-8 without BOM is the safe universal choice: every modern player, browser and the WebVTT specification expect it. Legacy SRT files are sometimes encoded as Windows-1252 or Latin-1, which turns accented characters and CJK text into mojibake. If your uploaded file shows garbled characters, re-save it as UTF-8 in a text editor before converting. This tool reads pasted and uploaded text as UTF-8.