Caption export formats per platform

Pick the caption object from the player that will draw it. Short-form feeds need burned-in captions because muted autoplay will not enable a track. Long-form YouTube and course players need a sidecar — SRT or WebVTT — because the viewer expects a toggle, search needs text, and a second language should not require a new picture. Export format is a destination decision. It is not a house style.

Versely's caption generator burns pixels. That is the correct deliverable for TikTok, Reels, Shorts, and most paid social. It is the wrong sole deliverable for a 22-minute YouTube upload or an LMS lesson. If the same source has to live in both rooms, you make two objects from one transcript, not one file you hope both players will understand.

Burn-in for feeds and ads

TikTok, Instagram Reels, YouTube Shorts, paid social, and most in-app video slots play the picture you upload. They do not reliably play a sidecar you also attached. A muted autoplay session will not hunt for a caption toggle. If the words are not in the frame, they are not in the view.

Burn-in means the styled, timed lines are composited into the MP4. The look you picked is the look that ships. The platform cannot restyle it, hide it, or lose it on re-upload. That is the point, and it is also the cost: a language change or a timing fix is a new render, not a new text file.

Practical rules for that object:

• Lock the cut, then burn. Pixels do not ripple when you drop a bumper.
• Keep the block out of the chrome. Usernames, caption fields, and the button rail sit on the bottom and one side of a 9:16 frame. A line on the true bottom of the export is invisible in the feed.
• Read the transcript before you commit. A wrong product name on a mute feed is the whole ad.
• Do not also upload an .srt to a Reel and call the job done. The feed will play the picture. It will not play the sidecar.

The AI caption generator and the agent job transcribe-and-caption-my-video produce this object. Ads follow the same rule as organic short-form: the auction is full of muted thumbs. Burn the claim into the file the ad account uploads.

Stories and in-app placements that letterbox or cover more of the frame still want burn-in, with a stricter safe area. Recheck placement; do not reuse a TikTok-safe lower-third on a placement whose chrome is different.

SRT for interchange and YouTube long-form

SRT is numbered cues, start and end times with a comma decimal, and plain text. No colour, no position, no karaoke. Almost every editor, freelancer, and caption vendor can ingest it. That is why it is the interchange format even when it is not the format the player prefers.

YouTube long-form wants a closed track. Upload the video, then upload a caption file (YouTube accepts SubRip among other formats) or create captions in Studio. Viewers can toggle them, pick a language, and the words stay searchable. Burning English into a 20-minute master you will later need in Spanish is how you re-render twenty minutes per language.

Use SRT when:

• A client or a caption vendor has to edit words and times without opening your timeline.
• YouTube long-form, a podcast video, or a conference recording needs a closed track.
• You need an archive of what was said, timed, independent of the picture.

Do not use SRT when the destination is a muted short-form feed. A perfect .srt in the project folder next to a silent MP4 is not a captioned TikTok.

Times in SRT use a comma: 00:00:01,000. That character is the usual reason a renamed file fails as something else. Shift a whole track with a constant offset when you trimmed an intro; if captions drift further out as the video runs, that is a frame-rate mismatch and an offset will not fix it.

YouTube's own auto-sync can take a plain transcript and align it. If you already have clean words and do not need hand-timed cues, get a video transcript is the text job, and YouTube can be the aligner. If you need the cues exact — forced narrative, a course with on-screen type the captions must not cover — time the SRT yourself, or burn-in is the wrong debate and placement is the debate.

WebVTT for the web and for courses

WebVTT is the web-native caption file. HTML <track> elements expect it. Many course players, custom site embeds, and accessibility pipelines want .vtt rather than .srt. The file starts with a WEBVTT header. Timestamps use a full stop as the decimal (00:00:01.000), not SubRip's comma.

WebVTT can carry more than words: cue settings for line, position, size, align; regions; a STYLE block. Players may honour that layout. SubRip cannot represent it. Converting VTT to SRT keeps text and times and drops placement. That is fine when the destination ignores layout. It is a loss when you authored the caption off a face.

Use WebVTT when:

• The lesson lives in an LMS or a course player that implements <track>.
• A marketing site or docs site ships HTML5 video and needs a toggle.
• You need positioning the player will draw, not only words.

Do not send a .vtt to a short-form scheduler. Do not rename .srt to .vtt and hope. The header and the timestamp separator are enough for a player to reject the track. Convert on purpose. Versely's in-browser SRT to VTT converter handles the header and the decimal so you are not doing that by hand; it does not caption the video.

SDH — subtitles for the deaf and hard of hearing, with speaker IDs and non-speech in brackets — is a flavour of closed captions, usually delivered as VTT or SRT with extra annotation, not as a third file extension. Forced narrative is the other sibling: only the signs and foreign lines a same-language viewer still needs. Neither replaces burn-in on a Reel. Both belong on the long-form or course object when the brief asks for accessibility, not only for "words on screen."

One source, two objects, per destination

The workable pipeline is boring.

1. Lock the cut.
2. Get a clean transcript. Correct names, numbers, the claim.
3. For each destination, pick the object:
   • Feed / ad / Short / Reel / TikTok: burn-in MP4. Style is part of the edit.
   • YouTube long-form, podcast video, most "upload a caption file" forms: SRT (or YouTube's caption flow from the same words).
   • Course player, HTML embed, anything with <track>: WebVTT.
   • Vendor / archive / legal: SRT as the source of truth for words and times.
4. If the brief asks for both a Reel and a lesson from the same talking-head, burn the short and sidecar the long. Do not burn the long "for consistency."

Broadcast and festival deliverables still show up as "send an SCC" or "send a CAP." Those are specialist sidecar formats. Do not invent them from a TikTok export. If a broadcaster asked, you are in a caption vendor's job, not a social preset's.

EU-facing realistic synthetic media is a label on the asset at first exposure, not a caption format. Article 50 does not care whether you burned or sidecared. Put the disclosure where a person can perceive it, then caption the speech as the destination requires.

A team that picks one format and uses it everywhere will either re-render every language of a course or ship silent Reels with excellent .srt files. A team that picks per player captions twice from one transcript and ships both.

Export the object the player can actually use, then caption the feed cut in Versely.

FAQ

Can I upload an SRT to TikTok instead of burning captions?

Do not plan on it. The feed plays the picture. Muted autoplay will not enable a track. Burn the lines into the MP4 you upload.

SRT or VTT for YouTube?

YouTube long-form accepts several caption formats, including SubRip. Use SRT when you want the simplest interchange; use VTT when you already have web cue settings you need to keep. Do not burn English into the master if you will need more languages.

Why not burn captions into the course video so they cannot be turned off?

Because courses need language swaps, search, and a player the student controls. A burned English lesson is a new render per language and a problem for anyone who needs a different size or colour. Sidecar the course. Burn the promo clip that lives in a feed.