Burned-In Captions vs Subtitle Files

Two Axes, Not One

Almost every confused conversation about this topic is two questions being answered as one. They are independent, and separating them fixes most of the confusion in a single step.

Axis one is what the text contains. A caption is written for someone who cannot hear the audio, so it identifies who is speaking and describes non-speech sound that carries meaning — a door slamming, a phone buzzing, laughter under a line. A subtitle assumes the viewer hears everything perfectly and only needs the dialogue in text, typically translated. That is North American usage. British and much of European usage calls both "subtitles" and labels the first kind SDH, subtitles for the deaf and hard of hearing. The distinction survives because it is the one accessibility law and platform policy care about: a dialogue-only translation is not a caption track.

Axis two is how the text is delivered. Open means burned into the picture and always visible. Closed means carried separately and drawn by the player, so it can be turned off. Every combination exists: burned-in translated subtitles on an imported film, a closed caption track with full speaker IDs on a broadcast, and everything between.

One more correction that catches people: closed does not mean text. Blu-ray PGS tracks (.sup) and DVD VobSub tracks (.sub/.idx) are closed subtitles shipped as bitmap images of the text. You can switch them off, but you cannot search, index, restyle, reflow or translate them without running OCR first. Closed means separable, not readable.

The Formats, Precisely

"Subtitle file" is a family, and the members differ enormously in what they can express. Here is the same two lines of dialogue in the two formats you will actually be asked for.

SRT — SubRip. The lowest common denominator, and the only format essentially everything reads.

1
00:00:04,120 --> 00:00:06,480
So here's the part nobody tells you.

2
00:00:06,480 --> 00:00:08,900
It costs more than you think.

A cue number, a start and end timestamp, the text, a blank line. Note the comma before the milliseconds. SRT has no formal specification — it is a de facto standard inherited from the ripping tool it came from — no portable styling (some players honour <i>, <b> and <font color>; many strip them silently), and no way to declare its own character encoding. That last omission is why an accented French or Cyrillic SRT so reliably arrives as mojibake: the file was written as Windows-1252 or CP1251 and read as UTF-8, and nothing in the file could have said otherwise.

WebVTT — the W3C format that the HTML5 <track> element requires.

WEBVTT

NOTE Cue identifiers are optional but make diffs readable.

pricing-1
00:00:04.120 --> 00:00:06.480 line:85% position:50% align:center
So here's the part nobody tells you.

00:00:06.480 --> 00:00:08.900
<v Dana>It costs more than you think.

The file must begin with the literal string WEBVTT, the encoding is always UTF-8, and the millisecond separator is a period, not a comma — which is the single most common reason a renamed .srt silently fails as a .vtt. On top of SRT it adds cue identifiers, NOTE comments, REGION blocks, per-cue positioning settings (line, position, size, align, vertical), voice spans, and STYLE blocks carrying a CSS subset applied through the ::cue pseudo-element. It is also the format HLS uses for segmented subtitle playlists.

ASS — Advanced SubStation Alpha. A different class of thing entirely.

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, OutlineColour, Outline, Shadow, Alignment
Style: Pop,Anton,72,&H00FFFFFF,&H00000000,4,2,2

[Events]
Dialogue: 0,0:00:04.12,0:00:06.48,Pop,,{\an2\fad(80,80)}So here's the part {\c&H00E0FF&}nobody{\c&H00FFFFFF&} tells you.

Named styles carrying font, size, outline and shadow thickness, margins and numpad alignment, plus inline override tags for absolute positioning (\pos), movement (\move), fades (\fad) and per-syllable karaoke timing (\k). ASS is what almost every burn-in pipeline converts to internally, because libass — the renderer behind most command-line and web burn-in — speaks ASS natively. That is the quiet punchline of this whole comparison: the format expressive enough to describe a modern styled caption is the one no consumer platform will play as a closed track. Beyond these three there is TTML/DFXP and its streaming profile IMSC for professional delivery, SCC carrying broadcast CEA-608 data as byte pairs, and the embedded broadcast standards themselves — CEA-608, historically transmitted on line 21 of the NTSC vertical blanking interval at 480 bit/s per field, which is precisely why classic broadcast captions are capped at 32 characters per row and about four rows on screen.

What Burning In Actually Costs

Attaching a subtitle track to an MP4 or MKV is a remux: the picture and sound streams are copied byte-for-byte, a text track is added alongside, and the operation takes seconds with zero quality change. Burning in cannot work that way. Compositing text onto frames is a filter, and a filter cannot touch copied frames, so every frame has to be decoded, drawn on, and re-encoded. Three consequences follow, and all of them are measurable.

• A generation of compression loss on the whole picture, not just the caption area. You paid an entire re-encode to add text to the bottom eighth of the frame.
• Text is the worst case for the codec. Block-transform codecs approximate high-contrast, high-frequency edges badly, and a glyph edge is exactly that. Captions are where ringing and mosquito noise appear first, and holding the same visual quality with captions on screen costs more bitrate than without.
• The glyphs are frozen at render resolution. Every platform builds an adaptive ladder and serves whichever rung the viewer's connection can carry, so text sized to be comfortable at 1080p is resampled down with the picture on a 360p rendition. This is the real reason thin, light-weight caption faces disintegrate on mobile data and heavy display faces with a hard outline survive — the outline is the only thing left at that scale.

And there is no reverse gear. Removing burned-in captions means inpainting — detecting the text region and repainting those pixels from their surroundings and from neighbouring frames. That is an approximation, not an undo: it holds up over flat or slow backgrounds and falls apart over detailed motion, and the repaired region is always softer than what was there before.

Burned-In vs Subtitle File, Side by Side

Where This Bites in a Real Edit

You shoot a twelve-minute talking-head piece. It goes to YouTube as 16:9, and three moments of it become vertical cut-downs for Reels, TikTok and Shorts. You caption everything, because feeds autoplay muted and an uncaptioned talking head in a feed is a silent stranger moving their mouth.

The first thing that goes wrong is order of operations. You burn the captions into the 16:9 master, then crop it to 9:16 for the vertical cuts — and the crop takes the ends of every caption line with it, because a burn is picture and picture is what a crop removes. The fix is not a setting, it is a sequence: reframe first, caption second, or caption at the output frame so the text is laid out for the frame it will actually be viewed in. Same reason the vertical cut needs its own safe margins: the app's own interface — username, description, the button rail — covers the bottom and right of a 9:16 frame, and it is drawn over your pixels after you have lost the ability to move them.

The second thing that goes wrong is the typo. The transcript heard "Kubernetes" as three other words, and it is burned into thirty seconds of the master. There is no text file to correct. The only route is back to the edit and out through another render — which is cheap if your captions were generated from a transcript inside a project, and genuinely expensive if the burn happened in a one-way export tool.

The third is the one almost nobody predicts: double captions on YouTube. YouTube generates its own speech-recognition caption track for your upload, and a viewer who keeps CC switched on gets that track drawn on top of the captions you burned in — two sets of text, differently worded, stacked. On a platform that accepts a sidecar, the correct move is to upload the long version without a burn and supply a caption file, keeping the burn for the short-form cuts where no sidecar would have survived the repost anyway. The decision is per-destination, not per-video.

Common Misconceptions

How This Works in Valmera

Valmera burns captions in. They are generated from an automatically detected transcript with word-level timing, and because the agent edits a decision list rather than pixels, the captions are timed against the finished edit — cut a minute of dead air and the caption cues land on the program that survives, not on the recording. The caption system is where the burn-in trade-off is being spent deliberately:

• 11 presets and 12 bundled font families (Anton, Bebas Neue, Playfair Display and Montserrat among them), any colours including a per-word highlight, sizes S–XL plus continuous scale, bottom/middle/top placement and 1–16 words per caption.
• Karaoke word-pop up to 6 words per line, 9 entrance animations and per-word emphasis — the class of look that only exists because the text is painted into the frame. See karaoke captions.
• Captions rescale to the output frame. Reframing to 9:16, 1:1 or 4:5 is part of the same render, so the caption is laid out for the frame it ships in rather than cropped along with the picture — the order-of-operations failure from the scenario above cannot happen.
• A typo costs a re-render, and a re-render is cheap. The transcript is editable and captions re-render from it, your original upload is never modified, and the final render always comes from that original file at source quality. That is the whole reason the "burned means permanent" objection is softer inside a project than inside a one-way export tool.
• The agent looks at the frames it produced, so a caption colliding with a lower third or running off the safe area is something it can see and say, rather than something you discover after posting.

The honest limits. There is no SRT or VTT import or export — no sidecar comes out, so you cannot hand a caption file to YouTube or LinkedIn, and the export carries no closed-caption track. There is no per-speaker diarization output and no chapter metadata. Custom font uploads are not supported; the 12 bundled families are what you have. English is the best-tested transcription path. If your deliverable is a caption file rather than a finished video, that stage belongs in a tool built for it. In the other direction, Valmera can measure and repaint burned-in text already present in footage you did not create — a watermark, someone else's captions — with the inpainting caveat above intact.

Related Terms

Other entries in the Valmera video editing glossary that touch this one:

• Word-level timestamps — The clock every caption cue is cut from — and the only way karaoke word-pop can be timed at all.
• Transcription and ASR — Where the text comes from before anyone argues about how to deliver it.
• Aspect ratio — Why a burn made for 16:9 loses the ends of its lines when the frame is cropped to 9:16.
• Auto-reframe — Reframing has to happen before the burn, or it crops the burn along with the picture.
• Text-based video editing — Editing the transcript that the captions are generated from, rather than the captions themselves.
• Edit decision list — Why re-rendering after a caption typo is cheap: the edit is a document, not a file you overwrote.
• Silence detection — Cuts change the program clock, which is why captions must be timed against the edit and not the recording.

Frequently Asked Questions

Caption a Video by Describing It

Word-accurate burned captions, timed against the edit rather than the recording, styled in one sentence. 50 free credits, no card.