Convert SRT to VTT and back in your browser

Reading the WebVTT preview

The conversion preview shows the current cue list written as WebVTT. It begins with the WEBVTT signature, leaves a blank line, then writes each cue as a start time, an arrow, an end time and the text. Times use a dot before the milliseconds and no sequence numbers appear above the cues. The preview updates as you edit text or timestamps.

This preview is the quickest way to confirm that the file is structurally valid before download. Look at the header, the separator between milliseconds and the blank line between cues. If the preview shows text where a timestamp should be, the source cue was not parsed as a cue. The preview is generated from the table, not from the original file, so it also reflects any deletions or merges made in the editor.

Convert VTT to SRT

The other direction uses the same table. Import a .vtt file and the parser skips the WEBVTT line plus any NOTE, STYLE or REGION blocks. It reads dot or comma timestamps and ignores cue settings that follow the end time. The cues appear in the table, and Download SRT writes them with commas and sequential numbers.

This is a one-way loss of presentation details. A cue identifier, an alignment setting or a region reference is not stored in the list, so it cannot be written to SRT. The words and the millisecond timings survive. If a VTT file relies on positioning to place a sign or a speaker label, the SRT version will show that text in the default position. Keep the original VTT if positioning matters, and use the SRT copy only where plain cues are acceptable.

SRT to TXT: a transcript without timings

Download TXT produces the plain text of the cues, one line per cue, with no numbers and no timestamps. Empty cues are dropped. This is useful when you need a transcript for searching, quoting or translation, but it is not a subtitle file. A player cannot use it for timing, and a text editor will not show where each line appeared.

Because the text comes from the cue table, a line break inside a cue is preserved. If you want flowing prose, join the lines in a word processor. If you want a timed transcript, export SRT or VTT instead. The srt to txt route is also a quick way to inspect the wording without the distraction of timecodes, especially when you are checking names and numbers against the source audio.

What changes and what does not

The conversion preserves the cue text and the time values at millisecond precision. It does not preserve comments, styles, regions, cue identifiers or settings, because the editable table has no place to store them. It also does not reflow text. A cue with three lines stays a cue with three lines, even if the target player would prefer two.

A round trip is not lossless. Converting SRT to VTT and back returns the same words and timings, but anything WebVTT added in between — cue settings, regions, identifiers or NOTE blocks — is dropped the first time the file passes through the table. Even a direct SRT to VTT to SRT trip produces a plain file, not the original bytes. If the source carried styling that matters, treat the converted copy as a new delivery file and keep the original.

Inline markup is left as text. A tag that was meaningful in one format may not be understood in the other, and this tool does not translate styling syntax. Treat the output as a clean cue list rather than a full format transplant. If the source is an SRT with informal bold or italic tags, check how the target player renders them before publishing. If the source is a styled VTT, expect the styling to disappear.

Encoding and line endings

The importer strips a UTF-8 byte-order mark and normalises Windows and old Mac line endings. The exporter writes a Blob with a UTF-8 charset, so accented letters and non-Latin scripts are stored consistently. What it cannot do is guess the encoding of a file that was saved in a legacy code page. If the imported text looks like random symbols, the source was not UTF-8 and the browser read it with the wrong assumption.

In that case, open the original in an editor that can convert encodings and save a UTF-8 copy before importing it here. The page has no encoding picker and no character-set repair. It also does not report encoding as a validation issue; it simply displays what the browser decoded. This is one reason to keep the original file until the exported subtitle has been checked in a player.

Choosing the right format for the player

Use VTT for HTML5 video, especially when the player loads a track element. Browsers understand the WEBVTT header and dot timestamps natively. Use SRT for desktop editors, older players and upload forms that ask for a subtitle file without offering WebVTT. Use TXT only for reading, searching or sending words to another person.

The extension is not the conversion. Renaming an SRT to end in .vtt leaves commas and no header, and a strict player may reject it. This page rewrites the header and separators for you. If you need to know which format a platform expects, check its upload instructions rather than guessing from the file picker. The SRT vs VTT guide explains the differences in more detail, and the VTT overview covers the header and cue model.

A practical conversion checklist

A short routine avoids most conversion surprises. Import the file, confirm the cue count, scan the first and last cues, make any text corrections, and look at the preview before downloading. Export the target format, then test it in the player that will actually use it. If the player has a caption menu, make sure captions are switched on.

Keep both the original and the converted file until the new one is verified. The page does not save anything, so closing the tab discards the table. If you are converting a batch of files, do them one at a time and name the outputs clearly. For timing repairs before conversion, use the timing editor; for structural warnings, use the subtitle validator.