Burned-In vs Soft Subtitles: Choosing a Delivery Format

Two Fundamentally Different Things

Subtitles arrive in two forms, and they are not variations of one deliverable — they are different products with different properties.

Burned-in subtitles, sometimes called open captions or hardsubs, are rendered into the video frames themselves. They are pixels. They cannot be turned off, restyled, or extracted, and they cannot be broken by a player.

Soft subtitles are a separate text track — a sidecar file or an embedded track — that the player renders at playback time. They can be toggled, restyled, selected by language, extracted, indexed, and translated. They can also be ignored, rendered badly, or unsupported.

Choosing between them is not a quality decision. Both can be excellent. It is a decision about who controls rendering, what the platform supports, and what you need the subtitles to do beyond being read.

The Case for Soft Subtitles

Soft subtitles are the default for good reasons, and for most professional delivery they are the right answer.

Multiple languages in one asset. A single video file can carry a dozen subtitle tracks, and the viewer picks. Burned-in subtitles require a separate video render per language, multiplying storage, encoding, and distribution cost.

Viewer control. People can turn subtitles off, and many want to. Forcing them on a viewer who does not need them is a worse experience.

Accessibility. Screen readers, braille displays, and assistive technology can access text tracks and cannot access pixels. Accessibility standards and regulations generally assume selectable text tracks, and some require them explicitly.

Search and discoverability. Platforms index subtitle text. A video with a soft subtitle track is findable by its spoken content; one with burned-in subtitles is not. For content where organic discovery matters, this is a significant advantage.

Styling adapts to context. Players size and position subtitles appropriately for the screen, and viewers with visual impairments can increase size or change contrast.

Correctable after publication. A typo in a soft track is fixed by replacing a small text file. A typo in a burned-in subtitle requires re-rendering, re-encoding, and re-uploading the entire video, which on some platforms also resets accumulated engagement metrics.

Reusable downstream. The same file becomes a transcript, a translation source, and an input to search indexing.

The Case for Burned-In Subtitles

Burned-in subtitles solve a specific set of problems that soft tracks cannot.

Guaranteed rendering. You control exactly how the text appears, on every platform, on every device. Nothing can render it wrongly because it is already rendered.

Complex scripts and right-to-left text. This is the strongest technical argument. Scripts with combining marks, cursive shaping, or bidirectional layout — Arabic, Persian, Hebrew, Devanagari, Tamil, Thai, Yoruba with tone diacritics — depend entirely on the player's rendering support. Where you cannot verify that support, burning in eliminates the risk. A soft Arabic track rendered by a player without bidirectional support is unreadable; a burned-in one is not.

Platforms with weak or no subtitle support. Several social platforms have historically offered poor subtitle handling, and some contexts — embedded players, in-app video, digital signage — offer none.

Sound-off viewing by default. A large share of social video is watched muted. Burned-in text guarantees the message lands without the viewer needing to enable anything, which measurably improves completion on those platforms.

Styled and designed captions. Where captions are part of the visual design — animated word-by-word captions, brand typography, deliberate positioning around on-screen elements — burning in is the only way to guarantee it.

Preventing removal. Where subtitles carry required disclosure, warning, or attribution text, burning in ensures it cannot be switched off.

The Hybrid Approach

The two are not mutually exclusive, and the most robust delivery frequently uses both.

Burn in the primary language, soft-track the rest. A video with burned-in English and soft tracks for eight other languages serves the default viewer reliably and the rest flexibly.

Deliver both versions of the same asset. A burned-in master for social distribution and a clean master with soft tracks for platforms that support them. The extra render cost is modest relative to the coverage gain.

Always produce the text file regardless. Even where you burn in, generate and keep the subtitle file. It is the source for translation, the input to transcripts, the basis for search indexing, and the artefact you will need when you inevitably have to fix something.

That last point is worth emphasising as a general rule: never let burned-in subtitles be the only form the text exists in. Extracting text back out of pixels is possible and unreliable, and losing the source file turns every future correction and every additional language into a re-transcription job.

Platform Considerations

Support varies enough that the decision is frequently made for you.

Major video platforms generally have good soft subtitle support, including multi-language tracks and automatic indexing of caption text for search. Soft is usually correct here.

Social feeds vary. Some handle caption tracks well; others historically have not, and viewing is overwhelmingly sound-off and in-feed. Burned-in styled captions typically outperform.

Streaming and broadcast delivery almost always requires soft subtitles in specified formats, frequently formats beyond the web-standard ones, with positioning and styling encoded.

Learning platforms and internal systems vary widely and are worth testing rather than assuming.

Embedded and in-app players often have limited or no subtitle support, making burned-in the practical choice.

Digital signage and public display typically has no subtitle capability at all.

The practical approach is to establish, per destination, whether soft tracks are supported and correctly rendered — and specifically to test with your most complex script rather than with English.

Accessibility Is Not Optional

A point that deserves separating out, because it is frequently misunderstood.

Accessibility obligations in most jurisdictions assume or require selectable captions. Burned-in subtitles do not satisfy them cleanly: they cannot be turned off, cannot be restyled by a viewer who needs larger text or different contrast, and are not accessible to assistive technology.

Additionally, translated subtitles and accessibility captions are different deliverables. Accessibility captions in a given language typically require speaker identification and non-speech audio information, which translated subtitles omit. And the requirement applies to each language version — a Spanish-language video needs Spanish captions, not only Spanish audio.

Where accessibility compliance matters, soft tracks are effectively mandatory, and burned-in versions should be treated as an additional distribution format rather than as the compliance deliverable.

Production and Maintenance Cost

The cost profiles differ in ways that matter at scale.

Soft subtitles cost essentially nothing per additional language beyond the translation itself. One video file, many small text files. Corrections are trivial. Adding a tenth language does not touch the video.

Burned-in subtitles require a render and encode per language. Storage and distribution multiply by language count. Corrections require re-rendering and re-uploading. On platforms where re-uploading resets engagement metrics or breaks existing links, corrections carry additional cost.

For a two-language project the difference is negligible. For a library of two hundred videos in nine languages, it is the difference between nine text files per video and nine video renders per video.

This argues for soft as the default at scale, with burned-in produced selectively for specific distribution channels rather than as the primary format.

A Working Checklist

Default to soft subtitles for professional delivery, accessibility, and multi-language scale.
Burn in where the platform has weak subtitle support or none.
Burn in for right-to-left and complex scripts where you cannot verify player rendering.
Burn in for muted-by-default social feeds and for styled or designed captions.
Consider a hybrid: burned-in primary language plus soft tracks for the rest.
Always generate and retain the subtitle text file, even when burning in.
Never let burned-in pixels be the only place the text exists.
Test soft track rendering with your most complex script, not with English.
Treat accessibility captions as a separate deliverable requiring soft tracks.
Weigh per-language render and storage cost before choosing burned-in at library scale.

Deciding Per Destination

Rather than choosing one format globally, most organisations benefit from a documented decision per publishing destination.

A practical approach is a short matrix listing every place your video appears — each video platform, each social channel, the website player, the learning system, any in-app or embedded context, and any broadcast or partner delivery — with three columns: whether soft subtitles are supported, whether they render correctly for your most complex script, and what the default viewing context is.

That third column matters more than people expect. A destination where viewing is overwhelmingly sound-off and in-feed argues for burned-in regardless of technical support, because the subtitle a viewer has to enable is a subtitle most viewers will not see.

Filling this in once produces a clear rule per destination, removes the decision from every individual project, and surfaces the destinations where you need to produce both formats.

It also tends to reveal that the number of genuinely distinct answers is small — usually soft for the main video platforms and professional delivery, burned-in for social and embedded contexts, and both for a handful of places where the audience is split. Codifying that is considerably cheaper than deciding it repeatedly.

Review the matrix annually, since platform subtitle support does change, and a destination that required burned-in two years ago may now handle soft tracks properly.

Frequently Asked Questions

Which format should I use by default?

Soft subtitles, for most professional delivery. They support multiple languages in one asset, give viewers control, satisfy accessibility requirements, get indexed by platform search, and cost essentially nothing per additional language. Burn in selectively where a specific channel or script requires it, rather than as the primary format.

When are burned-in subtitles clearly better?

When the platform has weak or no subtitle support, when the script is right-to-left or uses complex combining marks and you cannot verify the player renders it correctly, when viewing is muted by default as on social feeds, when captions are part of the visual design, or when the text carries required disclosure that must not be switchable.

Do burned-in subtitles meet accessibility requirements?

Generally no. Accessibility obligations typically assume selectable captions that a viewer can enable, restyle, or enlarge, and that assistive technology can access. Burned-in pixels satisfy none of those. Where compliance matters, deliver soft tracks and treat any burned-in version as an additional distribution format.

Can I use both?

Yes, and it is often the most robust approach. Burn in the primary language and provide soft tracks for the others, or produce a burned-in master for social alongside a clean master with soft tracks for platforms that support them. The extra render cost is usually small relative to the coverage gained.

What is the most common mistake?

Letting burned-in subtitles be the only form the text exists in. Extracting text back out of pixels is unreliable, and losing the source file turns every correction and every additional language into a fresh transcription job. Always generate and archive the subtitle file even when your delivery format is burned-in.

Can burned-in subtitles be converted back to a text track later?

Only unreliably, through optical character recognition of the rendered frames, which introduces errors and loses timing precision. This is why the subtitle file should always be generated and archived even when your chosen delivery format is burned-in. Treating the pixels as the only copy turns every future correction, every additional language, and every accessibility requirement into a fresh transcription job.

Do burned-in subtitles affect video encoding quality?

Slightly, yes. Text with hard edges against moving footage is relatively expensive to encode, so at a fixed bitrate a burned-in version will show marginally more compression artefacting than the clean version. It is rarely visible at sensible bitrates, but it is a reason not to burn in unnecessarily on bandwidth-constrained delivery.