Burned-In vs Soft Subtitles: Tracks and Sidecars

What is the difference between burned-in and soft subtitles?

Burned-in subtitles are part of the video image; soft subtitles remain separately selectable when the playback system supports them. A sidecar holds timed text in a separate file. Choose by the viewer’s needs and the destination’s documented support, not the filename alone. Preserve authorized originals and caption assets, then check the delivered result before replacing any working copy.

A request to “include the subtitles” needs one more conversation. Does the recipient want one fixed presentation, several language choices, or a caption file to manage separately? Those are different deliverables. This guide compares the packaging choices and provides an original paper worksheet; it does not report software or playback tests.

What are the three delivery arrangements?

HandBrake’s subtitle documentation distinguishes permanent image rendering from selectable output tracks. Its terminology is useful, but the destination still needs to be specified.

“Embedded” is an especially ambiguous handoff word. Ask whether it means text painted into the image or an independently selectable stream packaged with the video. Write the answer explicitly rather than accepting a tick beside “subtitles included.”

For a project folder, our editorial preference is to retain the authorized clean source and separate caption assets even when a fixed viewing version is requested. Name each output by its purpose. A presentation copy and an editable source should not depend on someone remembering which file they opened last.

Are captions and translated subtitles the same choice?

Purpose and packaging are separate axes. W3C’s Web Accessibility Initiative describes captions as synchronized speech plus relevant non-speech audio information. Its guide uses “subtitles” for translation, while acknowledging regional differences in terminology. A dialogue translation should not simply be assumed to contain the information a viewer needs when they cannot hear the audio. WAI caption guidance

For the handoff, ask two independent questions: “What information must this text communicate?” and “How must the viewer receive it?” Record the intended language, audience and content scope before choosing the package. A menu item called English does not answer all three.

WAI also warns that automatically generated captions need accuracy review. Changing the delivery arrangement is not a substitute for that review. If accessibility requirements are part of a commissioned project, involve the responsible accessibility specialist; this comparison is not a compliance determination.

Why does the exact subtitle format matter?

A subtitle is not necessarily a string of editable letters. HandBrake distinguishes bitmap formats such as PGS from text formats such as SRT. Its current documentation says PGS cannot pass through to MP4, whereas multiple PGS tracks can pass through to MKV. That is a documented HandBrake output distinction, not a promise about every converter or player.

For a real request, complete a compatibility sentence: “This subtitle format, in this output container, must work in this named application and version.” If a recipient only supplies an extension, ask for the missing destination information.

Our guide to conversion without quality loss explains the wider container-and-stream decision. Keep the subtitle decision visible alongside it. A successful picture transfer is not evidence that every requested text asset has survived.

Do not approve an alternative merely because its name appears in an export menu. Ask the person responsible for delivery to document what changes, what stays selectable, and which original assets will be retained.

What does an SRT sidecar actually contain?

The Library of Congress’s preliminary SRT description, updated May 27, 2025, describes a text file containing numbered entries, start and end times, subtitle text, and separators. The file does not contain the video or audio itself. It also notes that formatting presentation can depend on the application. Library of Congress SRT description

That makes two inventory entries sensible: one for the media and one for the sidecar. In our proposed record, both receive the same project identifier but keep distinct filenames, revision numbers and purposes. This is an organizational convention, not an assertion that every player automatically matches files by those names.

Keep the delivered text file as well as the working version. If a colleague later reports a missing phrase, the record should identify which revision they received, not just which video title they remember.

Does putting SRT into MKV preserve the original file?

Not as an intact sidecar by definition. Matroska’s documented SRT mapping puts the subtitle text into its block data in UTF-8; the timing becomes block timestamps and durations. This is a representation of the subtitle information inside the container, rather than simply the complete original text file tucked away unchanged. Matroska subtitle mapping

Our practical conclusion is to keep the source sidecar independently. An embedded track may satisfy the viewing requirement while the original file remains useful for comparison and revision history. Those are different reasons to retain an asset.

In a handoff note, separate “text and timing checked” from “original file preserved.” Neither phrase should stand in for the other. This distinction also prevents an archive folder from being mistaken for a viewing-only delivery.

What changes for a web page?

MDN documents HTML’s track element as a way to associate WebVTT timed-text files with media. Its fields distinguish the track’s kind, language and user-visible label. Multiple tracks can be supplied; the documentation also describes user preferences in track selection. This is a particular web delivery mechanism, not a statement that an arbitrary video player accepts any sidecar. MDN track reference

A useful question for the web publisher is therefore: “Which timed-text file did you associate with this particular media revision?” Follow it with the intended label and language. Ask for a check on the actual published presentation, not only confirmation that a file was received.

There is no page code to run here. The publisher should follow current documentation for their implementation and report the resulting behavior.

How can a three-cue record expose an incomplete handoff?

The following is an original fictional planning example, not a caption file, media test, translation or recommended reading-speed schedule. All times are elapsed seconds from the same imaginary clip start.

Subtracting start from end gives 2.000, 1.500 and 2.500 seconds: 6.000 seconds of scheduled display in total. The gaps are 1.500 and 2.000 seconds. Nothing in that arithmetic establishes synchronization with real speech, sufficient reading time or complete caption coverage.

For this example, suppose the fictional request is an English caption option that viewers can select. A delivery report should answer:

• Which exact media and text revisions were used?
• Are all three entries present with their intended wording and timing?
• How is the option identified to the viewer?
• Was its selection checked in the named destination?
• Where are the retained source assets?

If the report only says “three entries exported,” the selection requirement remains unanswered. If it says “English option present,” the content check remains unanswered. Mark those as unresolved questions, not passed tests.

What should the final acceptance note say?

Our suggested acceptance note separates content, timing, presentation and preservation. For each, record the reviewer, the exact output revision, the destination checked and any unresolved issue. Do not replace those fields with a single “looks fine.”

For content, compare the requested text with the delivered version. For timing, describe what was actually reviewed rather than extrapolating from the first cue. For presentation, record the observed selection and display behavior in the destination. For preservation, identify the retained originals and backups.

The file-size decision guide helps keep caption requirements separate from compression targets. Do not silently remove an accessibility asset to meet a smaller-file request; bring the conflict back to the person setting the delivery requirements.

Work only with media and text you are authorized to process. Respect licenses and access controls, and do not submit private recordings to an unapproved service. Keep originals and backups before changes. A format decision does not grant permission to copy, distribute or bypass protection.

For related terminology, the Format Basics collection provides the next layer. The useful endpoint is a precise handoff: what the text contains, where it is stored, how the intended viewer accesses it, and what was actually checked.

Sources

Primary documentation checked September 8, 2026: HandBrake’s current subtitle guide; W3C WAI’s caption guidance, updated September 17, 2024; the Library of Congress’s May 2025 SRT description; Matroska’s subtitle mapping; and MDN’s track reference, modified April 24, 2026. All are linked beside their supported claims. The inventory and three-cue worksheet are original editorial examples, not rendered-output testing.