Burned-in vs SRT and VTT subtitles: which format to choose

Burned-in vs file-based: the core choice

There are two ways to put subtitles on a video. Burned-in subtitles, called incrustés in French and also known as open or hardcoded captions, are rendered permanently into the video image. File-based subtitles, mainly SRT and VTT, travel as a separate text file that a player overlays at playback and the viewer can toggle.

Everything else, styling, editability, accessibility, platform support, flows from that one difference: are the subtitles part of the picture, or a layer on top of it.

You will also see this framed as open versus closed captions. Burned-in subtitles are open captions: they are part of the picture and always visible. File based subtitles (SRT, VTT and the rest) are closed captions: they ride alongside the video and the viewer can turn them on or off. Open versus closed is the same decision as burned-in versus separate file, in the vocabulary the broadcast and accessibility worlds use.

What "incrusté" (burned-in) means

Burned-in subtitles are part of the video pixels, so they need no player or track support to display, and the viewer cannot turn them off, and you can style them without limit: any font, colour, position, animation or background. That is why social and motion work usually burns them in.

The cost is rigidity. The viewer cannot turn them off, you cannot offer a second language without a second export, and fixing a single typo means re-rendering and re-uploading the whole video. They are also invisible to search engines and screen readers, because they are pixels, not text.

SRT and VTT: the file formats

SRT (SubRip) is the universal plain-text subtitle file: a numbered list of cues with start and end timecodes (written with a comma, 00:00:20,000) and the text. It carries no styling and is accepted almost everywhere, from YouTube and Vimeo to most players and learning platforms.

VTT (WebVTT) is the web standard, built for the HTML5 video track element. It opens with a WEBVTT header, uses a dot in its timecodes (00:00:20.000), and supports basic styling and positioning via CSS. Use SRT as the safe default and VTT when you are delivering to the web. The table above compares them with burned-in.

Beyond SRT: EBU-STL, ASS, SCC and TTML

SRT and VTT are the everyday formats, but they are not the only ones, and broadcast or platform delivery sometimes asks for others. EBU-STL (.stl) is the European broadcast subtitle standard, still requested by TV channels. ASS or SSA (Advanced SubStation Alpha) carries styling and positioning the plain formats cannot, which is why it shows up in anime and fansubbing. SCC (Scenarist Closed Captions) carries CEA-608 captions for US broadcast delivery. TTML, and its IMSC profile, is the XML based timed-text format the streaming platforms use under the hood; Netflix delivery, for instance, runs on IMSC.

For most web and social work you will never leave SRT and VTT. The moment a broadcaster or a streaming aggregator is involved, ask which format and which spec they expect, because a file in the wrong format is a redelivery, not a quick fix.

Which to use, by destination

Match the format to where the video plays. YouTube, Vimeo and most players take an SRT or VTT file, so deliver a file and keep the video clean. The open web (an HTML5 player on a site) wants VTT. Learning platforms usually accept SRT.

Burn in only when the destination gives you no choice: Instagram and TikTok do not let you upload an SRT or VTT sidecar file for in-feed video (they offer only auto-generated platform captions with limited styling), and feeds are watched on mute, so when you need full design control or reliable accuracy the text has to live in the picture. When in doubt, deliver both: a clean master plus an SRT, and a separate burned-in version for social.

Subtitles vs captions (SME / SDH)

Format is one axis; purpose is another. Subtitles assume the viewer can hear and only render speech. Captions add speaker identification and non-speech sounds for deaf and hard-of-hearing audiences. France uses the colour-coded SME standard; SDH is the English-language equivalent, which serves the same purpose with its own, usually monochrome, conventions.

Either can be delivered as a file or burned in, but accessibility captions are almost always file-based so the viewer can enable them on demand. Do not confuse the two: a brief asking for accessibility wants SME captions, not plain subtitles.

The hidden trade-offs: editing, accessibility, SEO

File-based subtitles win on everything except styling. You can fix or retranslate them in seconds without touching the video, reuse one master video for every language, and let the viewer choose. They are also machine-readable, so search engines can index the words and screen readers can announce them.

Burned-in subtitles win only on look. They give total design control and guaranteed display, which matters for branded social content, but they sacrifice editability, multilingual reuse, accessibility and discoverability. The right call is usually file-based unless the platform or the design demands otherwise.

Delivering subtitles from DaVinci Resolve

DaVinci Resolve does both. You can create a subtitle track and export it as SRT for a file delivery, or render the subtitle track into the picture for a burned-in version, choosing font, size and position on the way out.

The practical workflow is to keep subtitles as a file for as long as possible and only burn in at the final export for the platforms that need it. That keeps one clean master, makes typo fixes cheap, and preserves an accessible, searchable file for everywhere else.