ALL DEVELOPER TOOLS56
Subtitle Converter
Subtitle Converter — SRT, WebVTT and ASS
Convert between SRT, WebVTT and ASS, shift every cue by a fixed offset, or re-time a file that was timed for a different frame rate.
About Subtitle Converter
Three things go wrong with subtitle files, and this page fixes all three. The first is the format: a player wants WebVTT and you have an SRT, or a site wants an SRT and someone sent you an ASS. The second is synchronisation — the words arrive two seconds before the mouth moves — which is a fixed offset applied to every cue. The third looks like the second and is not: a file timed against a 23.976 fps transfer and played at 25 drifts further out the longer it runs, because the error grows with elapsed time instead of staying constant. That one is fixed by re-timing between the two rates, which multiplies every cue time by timed-for over playing-at; getting the ratio the wrong way up doubles the drift rather than removing it, which is why the two rates are picked separately rather than guessed. The formats differ in small mechanical ways that break parsers. SRT writes its milliseconds after a comma and WebVTT after a full stop; WebVTT will not load in a browser without a WEBVTT line at the top; ASS stores hundredths of a second rather than thousandths, so writing ASS rounds outward, starts down and ends up, by up to 10 ms. All of that is handled. What cannot be handled is the other direction. ASS is a different model altogether — named styles, fonts and colours, on-screen positioning, karaoke timing inside the text itself — and converting one to SRT keeps the words and the times and discards every bit of the rest. The count of what went is printed rather than hidden: the cues that were vector drawings instead of words, the markup that had nowhere to go. Writing ASS produces a valid file with a single Default style; it is not a styled one. Encoding is the other half of the job. Subtitle files in the wild are frequently not UTF-8 — an older SRT is very often Windows-1252 — and reading one of those as UTF-8 with a forgiving decoder puts a replacement mark where every accent was, which is a file that looks converted and is quietly ruined. So the encoding is worked out rather than assumed: a byte-order mark is believed, BOM-less UTF-16 is spotted by its zero bytes, and the UTF-8 test is run strictly so that a file which is not UTF-8 fails it instead of coming back full of diamonds. Bytes that fail are read as Windows-1252 and labelled a guess, because a Cyrillic or Greek file is equally valid non-UTF-8, and a picker lets you name the codepage yourself when the guess is wrong. What gets written out is always UTF-8. The last of it is arithmetic on the timings. A negative shift that would start a cue before zero has that start pulled to 00:00:00; a cue that ends before zero is dropped rather than written out invalid; cues are sorted by start time and the SRT and WebVTT output is renumbered from 1; and overlapping cues are left exactly as they were, because two people talking at once is legal. Every one of those is counted on screen. Nothing is uploaded — the file is read, converted and written in this tab.
Questions
My subtitles drift further out the longer the video runs.
That is a frame-rate problem, not an offset problem, and shifting the file will not fix it — the error grows with elapsed time instead of staying constant. It happens when a file timed against 23.976 fps is played at 25, or the reverse. Use the frame-rate re-time instead: give it the rate the file was timed at and the rate you are playing at, and every timestamp is scaled rather than nudged.
What is lost converting ASS to SRT?
Everything except the words and the times. ASS carries named styles, fonts, colours, on-screen positioning and karaoke timing inside the text itself, and SRT has nowhere to put any of it. The conversion keeps the dialogue and the cue timings and drops the rest, and it tells you what it dropped — the cues that were vector drawings rather than words, the markup with nowhere to go. Going the other way cannot invent styling that was never there: writing ASS gives you a valid file with one Default style, not a styled one.
What if my file is not UTF-8?
It is read anyway, and the guess is shown rather than hidden. Detection believes a byte-order mark, spots BOM-less UTF-16 by its zero bytes, and otherwise tests the bytes strictly against UTF-8 — strictly, because the forgiving decoder every browser uses by default would replace each accented character with a diamond and report success. Bytes that fail the strict test are read as Windows-1252 and flagged as a guess, since a Cyrillic or Greek file is equally valid non-UTF-8; when the guess is wrong, the READ THE FILE AS picker lets you name the codepage. Everything written out is UTF-8, with an optional byte-order mark for the few players that insist on one.
Does this burn the subtitles into the video?
No. This is a text tool: subtitles in, subtitles out. Burning captions into the picture means re-encoding every frame of the video, which is a different job entirely and is not what this page does. What you get is a sidecar file to sit next to the video, which is also the version a viewer can turn off.
What happens if a shift pushes a cue before zero?
Its start is pulled to 00:00:00 rather than written out as a negative time, because no subtitle format can express one and a player handed a negative timestamp will either ignore the cue or refuse the file. A cue whose END also falls before zero has nothing left to show and is dropped instead. Both are counted on screen, so a shift that quietly cost you the first three lines cannot pass for a clean run.
Is my file uploaded to a server?
No. Transmute processes everything locally in your browser using JavaScript and WebAssembly. Your files never leave your device — there is no server, no upload, no cloud processing.