The short answer
Posting to Reels, Shorts, TikTok or a LinkedIn feed: burn them in. Those surfaces re-encode your upload, autoplay muted and will not carry a sidecar file through a download or a re-share.
Uploading to YouTube as your primary destination, publishing to a site you control, or delivering to a broadcaster or client: use a subtitle file. You get searchable text, selectable languages, a viewer who can switch them off, and no quality loss at all.
Doing both: upload the video with an SRT to YouTube and a burned-in version everywhere else. They are not mutually exclusive, and the only cost is one extra export.
What the two things actually are
A subtitle file — .srt, .vtt, .ass — is a plain text file of timestamps and lines. It sits beside the video, and the player reads it and draws the text at playback time. The video file itself contains no captions. This is what "closed captions" means: closed because the viewer can close them.
Burned-in captions, also called open captions or hardcoded subtitles, are drawn into the video frames during encoding. The words become pixels, indistinguishable from anything else in the picture. There is nothing to load and nothing to switch off.
That is the whole technical difference, and almost every practical consequence follows from it.
Where subtitle files genuinely win
They are editable after the fact. Spotted a typo a week after publishing? Replace the text file. With burned-in captions you re-render and re-upload, which on most platforms means losing the post's existing engagement.
They carry multiple languages in one video. One upload, a dozen subtitle tracks, viewer picks. Burning in means one video per language.
They cost nothing in quality. Because the video is never re-encoded, there is no generation loss whatsoever. A burned-in export re-compresses every frame.
They are machine-readable, which matters more than people realise. The text is searchable, indexable and can be read by a search engine or an AI assistant. YouTube uses subtitle tracks for search. Burned-in captions are pixels — nothing can read them without running OCR.
And they let the viewer turn captions off, which some people genuinely want.
On engineering merit, sidecar files win clearly. If platforms handled them reliably, this comparison would not be interesting.
Why social platforms break them anyway
Platforms re-encode what you upload. Your file is transcoded into their own formats and ladders, and a sidecar file is not part of the video — so unless the platform has explicit support for uploading and retaining one, it is simply not carried through.
Downloads and re-shares strip it. Someone saves your clip and posts it to their own account, or sends it in a message, or screen-records it. All they have is the video.
Embedded and in-feed players often do not load subtitle tracks even when the platform stores them.
And feeds autoplay muted. This is the decisive one. The first seconds of your clip are silent by default, and whether someone stops scrolling depends on whether they can tell what is being said without hearing it. Captions are not an accessibility add-on in that moment — they are the only channel carrying your words during the window that decides whether you get a viewer at all. Captions that depend on the player cooperating are captions that are frequently just absent.
What burning in actually costs
Be clear-eyed about it. Three real costs.
It is irreversible. Once the words are pixels, fixing a typo means rendering and uploading again. This is why it matters that a tool keeps captions as editable data up to the moment you export, and lets you re-export from the same source as often as you like — the mistake should cost one render, not a re-edit.
It re-encodes the video. Every frame the captions touch has to be redrawn, so the whole file is encoded again, and any re-encode is lossy in principle. At a sensible quality setting the difference is not visible in normal viewing, but it is not zero. Audio can be copied across untouched, so sound loses nothing.
It takes time. Render duration scales with clip length and resolution, because there is no shortcut that avoids writing new frames. A 30-second vertical clip is quick. A 40-minute video is a genuine wait. Any tool that burns captions in has this constraint — if one claims instant export on long video, it is not burning anything in.
The accessibility question
Worth addressing honestly, because burned-in captions are sometimes described as an accessibility win and that is only partly true.
They help in that the captions are always present — no viewer has to find a setting, and no player can fail to offer one. For deaf and hard-of-hearing viewers on platforms that handle subtitles badly, burned-in captions are the difference between accessible and not.
They hurt in that they cannot be adjusted. A viewer who needs larger text, a different colour for contrast, or a screen reader cannot do anything with pixels. Proper closed captions respect user preferences; burned-in captions override them. They also cannot be translated by the viewer, and they cannot be turned off by someone who finds them distracting.
If you are publishing in a context with formal accessibility requirements — education, government, broadcast — use real closed captions. Burned-in captions are the pragmatic answer for social video, not the accessible-by-definition one.
A decision you can act on
Short-form social video, where most of your views come from a muted feed: burn them in, and style them for legibility over your actual footage rather than accepting a default overlay.
YouTube as the main destination: upload a subtitle file. YouTube handles them well, uses the text for search, and lets viewers translate them. Many creators also burn in captions for the first few seconds as a hook and leave the rest to the subtitle track.
Client or broadcast delivery: ask, and expect them to want a sidecar file. Burning in removes options they may be contractually required to keep.
Your own site: subtitle files, since you control the player and can guarantee it loads them.
And if a clip is going to several places, export twice. The captions are the same work either way — only the final render differs.