Burned-In Captions vs SRT and VTT Sidecars

Two completely different things get called "adding captions" to a video, and the difference is not stylistic. One of them changes the pixels — text rendered permanently into every frame it appears on, part of the image itself from the moment it's rendered. The other adds nothing to the picture at all: a separate text file, timed to the video, that a player reads and draws on top at watch time. Both end up looking like captions on screen. Only one of them is still text underneath, and that distinction decides whether the same video can be searched, translated, or turned off — not a preference, a structural fact about which object you actually shipped.

What burned-in actually buys you

Baking captions into the frame has two real advantages, and both come from the same property: the text is pixels now, not a separate layer the player has to be told to render. It survives a re-upload or a re-host with zero extra effort, because there's no separate track to lose — download the file and hand it to a platform that has no caption system at all, and the words are still on screen. It also looks exactly as designed, because a burned-in caption can use any font, animation, or placement the render supports — picked deliberately from a real style, not a generic default — rather than whatever plain look a given platform's native caption renderer happens to apply. For a muted, autoplay-first feed — the default viewing mode on most short-form platforms — that combination is close to mandatory: you cannot afford the caption to depend on a viewer toggling anything on, and the caption's look is part of the edit rather than an accessibility afterthought bolted on separately. See burned-in captions for the fuller mechanics of what actually gets rendered.

What it costs you

The same property that makes burned-in captions durable makes them expensive in exactly two ways. They're unlocalisable without a full re-render: because the words are pixels, not characters, swapping English for Spanish means re-compositing the entire clip from scratch, frame by frame, rather than pointing the same video file at a different text file. A sidecar caption file solves that trivially — one video, several .vtt files, one per language, no touching the video itself at all. And they're unsearchable: a search index, a platform's own content-understanding system, or a simple Ctrl+F on a transcript page can all read a text file's contents directly, in milliseconds, at any scale. None of them can reliably read pixels rendered into a compressed video frame the way they read a line of text — burned-in words contribute nothing to how discoverable that video is anywhere text actually gets indexed, no matter how legible they are to a human watching.

What a sidecar file actually is

SRT is about as simple as a caption format gets: numbered blocks, each with a start and end timecode and one or more lines of plain text, no built-in styling and no structure beyond that. It's old, it's universally supported, and it's exactly expressive enough to say "these words, during this span of time" and nothing more. WebVTT is the W3C's own successor, purpose-built for the web's <track> element rather than adapted to it — the spec describes it as covering not just captions and subtitles but "text video descriptions" for vision-impaired viewers, chapter markers for navigation, and more general time-aligned metadata, which is a broader job than SRT was ever asked to do. Either format is the same basic idea: a plain-text file, separate from the video, that a player reads and times against playback.

Getting the timing right in either format is its own distinct step from writing the words down. Forced alignment is the process that takes a known transcript and works out exactly when each word was actually spoken — a different, easier problem than transcription itself, because the text is already known and only needs placing on the timeline. A sidecar file is only as good as that alignment pass; text with no accurate timing attached isn't a caption file yet, just a transcript with ambitions.

The per-destination rule

The two options aren't competing for the same job — they're suited to different destinations, and the mistake is picking one format and using it everywhere out of habit rather than choosing per platform. A short-form vertical feed — TikTok, Reels, Shorts — wants burn-in, because the viewing context is muted autoplay by default and the caption is functioning as part of the visual design, not as an accessibility toggle a viewer is expected to find. A YouTube long-form upload, a website embed, or anything headed for broadcast wants a sidecar file instead, because the player already has a native caption toggle viewers expect to use, the content is far more likely to need a second-language version at some point, and the underlying platform can actually index the words for search rather than seeing an opaque video frame. Getting this backwards is its own quiet failure mode: burning captions into a long-form video that was always going to need three language versions means re-rendering the whole thing three times over, and shipping a sidecar-only caption to a muted vertical feed means most viewers never see a caption at all, because they were never going to turn one on.

Where Versely sits in that split

Versely's own caption tools are burn-in tools, and it's worth being direct about that rather than implying otherwise: the styled, automatically-transcribed captions they produce are composited into the video frames, not written out as a separate track. That's the right tool for the short-form, muted-autoplay destination — but it means a sidecar workflow for the same footage doesn't start from those caption tools at all. It starts from transcribe_audio, the tool built specifically to return plain text rather than a burned-in track: it runs Cartesia's ink-whisper speech-to-text model against the audio and hands back the words themselves, editable and copyable, with nothing rendered onto the video. From there, most destinations that actually want a sidecar file — YouTube's caption upload flow among them — can take that plain transcript and auto-sync it against the audio on their own end, rather than requiring hand-timed cues built one by one.

A Versely walkthrough: one clip, two destinations

Say the same finished video needs to go to a TikTok feed and to a YouTube long-form upload — a genuinely common split, and a clean test of the per-destination rule. For the TikTok cut, the prompt is the burn-in path directly: "Transcribe and caption this video automatically, plain readable style, English." That calls the styled auto-captioning tool, which transcribes, aligns, and composites the result into the video in one pass — a finished file with no separate caption asset to manage, exactly right for a feed where nobody's reaching for a caption toggle.

For the YouTube upload of the same underlying footage, the request changes shape: "Get me a plain transcript of this video's audio" calls transcribe_audio instead, returning the words with none of them burned into any frame. That transcript is what gets uploaded through YouTube's own captioning flow rather than pasted onto the video a second time — the platform handles the alignment on its own end, the words stay indexable and translatable, and the same source footage now serves two destinations with two structurally different caption deliverables, chosen on purpose rather than by whichever tool happened to be open first.

Takeaway

Burned-in and sidecar aren't two styles of the same feature — one is pixels, permanent and self-contained; the other is text, portable and swappable. Burn-in wins on a muted, style-driven feed where nothing can depend on a viewer's toggle. A sidecar file wins anywhere the same footage might need another language, needs to be searchable, or is landing on a platform with its own caption system already built in. The rule that actually holds up is the boring one: decide per destination, not per habit, before a single frame gets rendered.