Two ways to keep text apart from the picture
Subtitles that are not burned into the picture usually reach the viewer in one of two ways. In the first, the text lives in a separate file stored alongside the video. In the second, the text is packaged into the same file as the video, as one of several streams. Both keep the words as text and let the player draw them at playback, so the viewer can usually switch them on or off. The difference is where the text is stored and who can change it.
Sidecar files
A sidecar file is a separate file that travels with a video, much as a sidecar travels with a motorcycle. A film file and its subtitle file might sit in the same folder with matching names, differing only in the extension and often in a language label.
How it works in practice:
- The video file is untouched. The text is a small document that a player loads when told to, or finds automatically by matching the name.
- The same video can have many sidecar files, typically one for each language, each with a clear name.
- On the web, a page can reference a sidecar file for a video element, so the browser loads it separately, which is how most web players handle external text.
Strengths. Sidecar files are easy to edit. If you spot a mistake, you open the text, fix it and replace the file, without touching the video. They are small, quick to send for review, simple to translate and easy to keep in version control. Adding a new language later means adding a file, not re-exporting the video. They also let different departments or vendors work in parallel on text and picture.
Weaknesses. The file can get separated from the video. If someone copies the video and forgets the text, the viewer gets no subtitles. Names must match what the player expects, or the player will not find the file. Also, not every player or platform will accept a loose file, and those that do may accept only certain formats. The overview of file formats lists the common choices.
Embedded subtitles
An embedded subtitle track is packaged into the video file itself, inside the container that holds the picture and sound. A container is the wrapper that keeps video, audio and other streams together and in sync. Common container formats can hold several audio tracks and several subtitle tracks at once, and some players can pick which one to show.
How it works in practice:
- When the file is created, the text is multiplexed, or “muxed”, into the container alongside the video and audio.
- The video is generally not re-encoded to add the text, so the picture quality does not change. The new file is simply a repackaged version of the original streams, though the details depend on the tools and formats involved.
- Tracks can carry labels such as language and sometimes flags, for example marking a track as intended for deaf and hard of hearing viewers or as containing only foreign-language dialogue.
- The way players list and choose between them is covered in the article on subtitle tracks and language selection.
Strengths. There is one file to move around, so the text cannot be left behind. Language labels travel with it. Players that understand the container can present the options consistently. For distribution to viewers, a single self-contained file is often simpler.
Weaknesses. Edits are less convenient. Fixing one typo generally means extracting the track, correcting it, and putting it back, or re-packaging the whole file. The text can only be changed with tools that understand the container. Not every container supports every subtitle format, and some players ignore certain embedded tracks. A subtitle stored as images in a container also behaves differently from a text one, since it cannot be searched or resized cleanly.
Which one is which on a streaming or broadcast path
In professional delivery, the picture-and-sound master is often sent together with separate text files, and the delivery system packages them into its own formats later. In that setting, you are usually delivering sidecar files that the platform then embeds or converts. Because each platform has its own rules about accepted formats and naming, check the specification before you export. Do not assume what works in a desktop player will be accepted by a platform.
Practical habits
- Name files systematically. Use the video’s name plus a language label, and follow the platform’s rules if it has any. Consistent names help automatic matching.
- Keep the sidecar as the source. Even if you embed tracks for distribution, keep the standalone text files. They are the easiest thing to correct and reuse.
- Test in the real player. Confirm that the track appears, is labeled correctly and shows the right language. Keep a quality checklist handy.
- Watch for duplicate text. If a video has an embedded track and a loose file with the same language, some players show both, or the viewer sees two lines of text. Check for this when you add one.
- Mind character handling. A file that displays well on one system can break on another because of character encoding. Sidecar files expose this problem more openly, since they are plain text, but embedded tracks can hold the same errors.
- Record changes. When a file is updated, note which version went into which release. Good version control saves effort when a client asks which text is live.
Which suits which situation
Sidecar files tend to suit workflows with frequent edits, many languages, web publishing and review by several people. Embedded tracks tend to suit files that will be downloaded, archived or shared as a single item, where keeping text and picture together matters more than ease of editing. Many teams use both: sidecar files as the working copies and an embedded version as the finished distribution copy.
Either approach differs from permanent text drawn into the picture, where the viewer cannot switch the words off; that alternative is covered in the piece on burned-in subtitles.