SRT, VTT, Plain Text or Burned In: Choosing a Caption Output

Once you have a caption track you have reviewed and believe in, there is a second decision that people tend to make by accident: what form it leaves in. Auto Subtitles will give you SRT, WebVTT, plain text, or captions burned into a copy of the clip, and those four are not variations on a theme. They are four different objects with different afterlives.

Picking wrong is rarely catastrophic and frequently annoying. Here is what each one actually is.

SRT is the one that goes everywhere

SubRip is the oldest and least ambitious of the caption formats, and that is exactly why it wins. A cue is a number, a time range, and some lines of text, separated by a blank line. There is almost nothing to get wrong.

Every video platform's upload form accepts it. Every editing application imports it. Every translation service takes it. If you are uploading to somewhere that will host the video and show its own caption button, SRT is the answer and you can stop reading this section.

What it does not carry is appearance. Positioning, colour, and font in SRT are either unsupported or supported by convention in a way that different players honour differently. If your captions must look a specific way, SRT is not where that decision lives.

WebVTT is SRT for the web, with the parts SRT lacks

WebVTT is the format the browser itself understands. It is what you attach to an HTML5 video with a track element, and it is what a self-hosted player on your own site will want.

It looks similar to SRT and is not identical: it opens with a WEBVTT line, and its timestamps use a full stop before the milliseconds rather than a comma. Handing an SRT to a player that wants VTT usually results in no captions and no error, which is an irritating way to spend twenty minutes.

It also supports cue positioning and styling properly, so if you need a caption to sit at the top of the frame for the ten seconds where something important is happening at the bottom, VTT is the format that can express that.

Rule of thumb: uploading to a platform, export SRT. Embedding a player on a page you control, export VTT.

Plain text is not captions at all

The text export drops the timing and gives you the words. That sounds like a lesser version of the other two and it is actually a different product.

A transcript is what you paste into show notes. It is what makes a video findable by search, because search engines read text and do not watch video. It is what a person skims when they want to know whether the video is worth eleven minutes. It is what you hand to a translator, or to someone who needs the content and cannot use video at all.

Exporting plain text alongside a caption file is close to free and it is the export most people forget. If you publish video anywhere with a description field, the transcript belongs in or near it.

Burned-in captions are pixels, and that is the whole trade

Burning in renders the caption text into the video frames themselves. The render keeps source resolution and frame rate and muxes the original audio back in, so the clip you get is the clip you had with words drawn on it.

What you gain is that the captions cannot fail to appear. They survive every platform, every player, every re-upload, and every autoplay-muted feed where nobody is going to press a caption button. For short social video this is not a preference, it is the format working as intended.

What you lose is everything that made the text text:

• A viewer cannot turn them off. Someone who does not need them, or who is watching in a language where your captions are noise, has no way out.
• A viewer cannot resize or restyle them. This matters more than it sounds. A significant share of people who rely on captions also need them larger or higher-contrast than your design chose, and a burned-in caption denies them that entirely.
• They cannot be searched, indexed, or translated. The words are no longer words.
• They are permanent. Fixing a typo means re-rendering.

For accessibility specifically, a selectable caption track is the stronger answer and a burned-in caption is the fallback. The best of both is unremarkable and slightly more work: burn in for the feed, and also publish the SRT wherever the platform will take one.

Burn-in has hard limits here and they are worth knowing before you plan around it. The absolute browser ceiling is 60 seconds of opaque output, or 30 seconds when transparency is being preserved in a WebM. A memory preflight can ask for something shorter or lower-resolution on a given device before it starts. Caption file export has no such limit, so a long video still gets its SRT.

Whichever you pick, keep the SRT

This is the only piece of advice in this article that applies in every case.

The caption file is the source. It is the thing you can correct, restyle, re-time, translate, feed to a different platform next year, and hand to whoever inherits the channel. A burned-in MP4 is a rendering of it, and a rendering cannot be turned back into its source.

Export the SRT even when you are burning in and have no plans to use it. It costs nothing and it is the artefact you will wish you had.

The part that decides whether any of this is worth doing

Everything above assumes the caption text is correct, and the first pass will not be.

Transcription mishears names, product names, technical vocabulary, overlapping speakers, and accents it has heard less of. It does worse in noise. It also will not guess your language: the source language is chosen before transcription rather than detected, deliberately, because a confident wrong guess silently mislabels the whole track.

So review every cue against the actual audio. The caption track is editable: correct the text, adjust start and end times, split a cue that is trying to hold two sentences, merge two that are fragments of one. This is the work, and it is the difference between captions that help and captions that are a liability.

A run is limited to 15 minutes of audio, and a device-aware memory check can ask for a shorter or lower-rate clip before it starts rather than failing part way. A refusal leaves the source untouched.

And it stays on your machine

Transcription runs on a pinned Whisper revision that downloads once, roughly 82 MB, after you approve that exact revision. Nothing downloads before you approve it, and nothing is sent anywhere afterwards.

For a lot of video that is a footnote. For a recorded client call, an internal training video, a medical or legal recording, or an interview with someone who agreed to talk to you and not to a transcription vendor, it is the entire reason to do it this way.