SRT vs VTT: choose the right subtitle file

Choose the destination before the extension

An SRT or VTT file stores timed text separately from your video. Neither file burns words into the picture, and changing the format does not improve the transcription. Start by checking the upload instructions for the player, editor or publishing service that will receive your video. If it explicitly asks for one format, use that format.

For a straightforward YouTube upload, basic SRT is a supported option: YouTube's documentation specifies plain UTF-8 and says SRT style markup is not recognized. For a website using the HTML track element, prepare WebVTT, usually saved with a .vtt extension. MDN documents WebVTT as the format for those browser text tracks. A hosted course platform can have its own upload requirements even when the eventual viewer uses a browser, so check that platform separately.

Polyglot creates, translates and exports SRT from your media on an Apple Silicon Mac. It does not currently import standalone SRT or export WebVTT. If your destination needs VTT, first review and export SRT in Polyglot, then convert a copy with a suitable subtitle editor or a careful plain-text workflow. Keep your original SRT and saved project.

Read a simple SRT cue

In a basic SRT file, each cue has a sequence number, a line containing start and end times, and the words to display. A blank line separates it from the next cue. Timestamps use hours, minutes, seconds and three millisecond digits, with a comma before the milliseconds.

Here is an invented two-cue example for a recording you own. Cue 1 begins at 1.250 seconds and ends at 3.500 seconds. Cue 2 begins at 4 seconds. The comma inside the spoken sentence is ordinary punctuation, and the accented name is part of the text. Both details should survive conversion.

1
00:00:01,250 --> 00:00:03,500
Welcome, Zoë.

2
00:00:04,000 --> 00:00:06,500
Keep the original recording.

Compare the same cues in WebVTT

WebVTT starts with a WEBVTT header followed by a blank line. Its timestamps use a decimal point before the milliseconds. Cue identifiers are optional; this example keeps 1 and 2 so you can compare the two files easily. The words and display times have not changed.

WebVTT can also describe cue placement, styles and other timed information. Those capabilities do not guarantee that an upload service will preserve every setting. For example, YouTube documents limitations on the WebVTT styling it accepts. Use the destination's supported subset, and judge the result in that destination's player.

WEBVTT

1
00:00:01.250 --> 00:00:03.500
Welcome, Zoë.

2
00:00:04.000 --> 00:00:06.500
Keep the original recording.

Convert a plain-text copy carefully

For a simple, unstyled SRT like the example, duplicate the file and open the copy in an editor that can save plain UTF-8 text. Add WEBVTT as the first line, followed by a blank line. Change the comma to a decimal point in each timestamp. Keep the arrow, cue text, cue order and blank lines between cues. Save the copy with a .vtt extension, ensuring the editor has not appended .txt or saved a rich-text document.

Do not replace every comma in the file: that would change sentences such as Welcome, Zoë. Only the timestamp separators need changing. Renaming .srt to .vtt by itself also leaves the content in the wrong syntax. For a long file, use a subtitle-aware converter with an explicit WebVTT export instead of making hundreds of manual changes, then inspect its output.

This small conversion recipe is for plain dialogue cues. If the source contains markup, literal angle brackets, ampersands, unusual cue settings or other special content, use an editor that handles WebVTT escaping and syntax. Do not assume that a text substitution preserves richer formatting. For confidential recordings, keep the conversion local too; uploading subtitles to a website exposes their text even if you never upload the video.

Give the new file the same edit and language identity as the original, for example workshop-v2.en.srt and workshop-v2.en.vtt beside workshop-v2.mp4. Convert each reviewed language file separately. A format change does not translate words or make an older subtitle file match a new video edit.

Check the conversion before delivery

Compare the original and converted files cue by cue. The number and order of cues should match. Check the text, names, numbers, punctuation and line breaks; accented letters should remain readable. Compare the start and end time of every cue as a time value: 00:00:01,250 and 00:00:01.250 both represent the same instant. If the converter merges cues or changes timing, investigate its settings before accepting the file.

Then load the file with the exact video edit in the destination player. Check the opening line, a passage near the middle and the final exchange, and play any difficult section at normal speed. Confirm that the right language track is selected, captions can be enabled, and line wrapping does not obscure useful visual content. File-level checks and playback checks catch different problems; both matter.

For a website you control, make sure the VTT URL actually returns the caption file and serves the text/vtt media type specified by W3C. An HTML error page saved under a .vtt URL is not a subtitle file. If the caption file is hosted on a different origin, ask the site developer to check the player's cross-origin configuration as well. You do not need to change your spoken text to fix a delivery problem.

Separate format problems from caption problems

If the upload rejects the file, check the accepted extension, plain-text encoding, header and timestamp syntax first. If the file loads but no words appear, check the player's subtitle setting, selected language and caption URL. If words appear consistently too early or late, confirm that you paired the subtitles with the correct media edit. Converting SRT to VTT does not repair an offset or gradual timing drift.

If captions lose styling, check what the destination supports instead of repeatedly converting the same file. If the words are wrong, correct the reviewed source and regenerate the delivery copy. Keep a record of which copy was uploaded so the next correction reaches the right video and language track.

Finally, readable dialogue is only part of an accessibility review. W3C's guidance on prerecorded captions includes identifying speakers when needed and conveying meaningful non-speech audio. Neither SRT nor WebVTT automatically supplies that information. Listen for what viewers need to understand, add and review it in your finishing workflow, and check the actual presentation. A successful file conversion is a delivery step, not an accessibility certification.

Keep exploring.