Subtitle converter

SRT and WebVTT, and why they are not quite the same

SubRip (.srt) is the older of the two and the one almost every video tool can read. A file is a run of numbered cues: an index, a timing line, one or more lines of text, and a blank line. Times are written hours:minutes:seconds,milliseconds — with a comma before the milliseconds.

WebVTT (.vtt) is the format browsers use for the HTML <track> element. It opens with a WEBVTT header line, the cue index is optional, times use a dot before the milliseconds, and the timing line can carry positioning settings after the end time (align:start, line:90%). It also allows NOTE, STYLE and REGION blocks that have no equivalent in SRT.

Ninety per cent of real conversions come down to those three differences: the header, the decimal separator, and the optional index. That is what this converter normalises.

What the converter actually does

Both formats are parsed into one internal cue model — a start time in milliseconds, an end time, and the lines of text — and the output is written from that model. Nothing is patched with a search and replace, so a file that goes in as SRT and comes out as SRT is re-serialised cleanly: indexes renumbered from one, timings padded to 00:00:00,000, blank lines where they belong.

• Format detection is automatic. A WEBVTT first line means WebVTT; anything else is treated as SubRip. The detected format is shown above the output.
• Both decimal separators are accepted on input, whichever format the file claims to be, because plenty of files in the wild mix them.
• Cue identifiers are optional. A numeric index, a named identifier, or no identifier at all all parse — and an index sharing the timing line is accepted too.
• WebVTT cue settings are tolerated on input and dropped on output; positioning does not survive a trip through SRT, and pretending otherwise would be worse than saying so.
• Plain text joins each cue’s lines into one line, with an optional [mm:ss] stamp in front if you want to keep the reference points.

When the file will not parse

A malformed subtitle file produces a specific error naming the line number, not a blank screen. “Line 14: expected a timing line like 00:00:01,000 --> 00:00:04,000 but found …” tells you where to look. The failures worth knowing about are a timing line whose end time is earlier than its start, an arrow written as -> instead of -->, and a file saved in an encoding other than UTF-8, which arrives as unreadable characters. A missing blank line between cues is tolerated rather than rejected — the parser stops a cue when it sees the next timing line.

Nothing is uploaded

The file picker uses your browser’s FileReader, which hands the contents to the page directly from disk. There is no upload, no temporary storage and no queue — open your network panel and convert a file if you want to confirm it. The download button builds the result as a Blob in memory, hands it to the browser as an object URL, and revokes that URL as soon as the download has started, so nothing is left dangling in memory.

That matters more than it sounds for subtitles specifically: caption files routinely go out under embargo with unreleased films, internal training material and customer interviews inside them, and “we only keep it for an hour” is not a promise most people should have to accept for a format conversion.

Common questions

Will the timings shift?

No. Times are parsed to whole milliseconds and written back at the same precision. SRT and WebVTT both store milliseconds, so a round trip in either direction is exact. If a source file uses one- or two-digit fractional seconds, they are padded to three digits (1:23.4 becomes 00:01:23.400), which is what every player already assumes.

Do styling tags survive?

Inline tags inside the caption text (<i>, <b>) are carried through untouched, because they are part of the text. WebVTT positioning settings, STYLE blocks and NOTE blocks are dropped — SRT has nowhere to put them.

Can I convert several files at once?

Not in this version. It is one file at a time, deliberately: batching would mean either a server or a much heavier page, and neither is worth it for a job that takes a few seconds per file.

Which should I use for the web?

WebVTT. It is the format the HTML <track> element requires, and it is what browsers will load for a <video> element. Keep SRT for desktop players, editing software and platforms that ask for it by name.

What about SSA, ASS or TTML?

Not supported. Those formats carry styling and positioning that cannot be represented in SRT, so a conversion would silently throw information away — the same reason cue settings are dropped rather than approximated.

Turning captions into something you can edit

Plain-text output is where most people end up: it is the fastest route from a video to a blog post, show notes or a summary. Two follow-on steps are usually worth it.

• Send the text to the transcript cleaner to rejoin the lines that captions broke mid-sentence and to tidy the spacing.
• Then strip the verbal tics with the filler word remover, and check the length with the word counter.

Writing captions faster in the first place

If you write or correct caption text by hand, most of the time goes on typing, not on timing. VoiceSnap Pro is a dictation app for macOS and Windows: hold one keyboard shortcut, speak, and clean punctuated text appears in whatever field your cursor is already in — including the caption editor you already use. Filler words are stripped automatically, punctuation and paragraph breaks are added as you speak, and every dictation is saved to a searchable notes library.

It covers 50+ languages with mid-sentence switching, takes a custom vocabulary for the names and acronyms generic models get wrong, and is a one-time purchase, not a subscription. Nothing you dictate is used to train AI models. The app has not shipped yet — join the waitlist to hear on release day.