Closed captions vs subtitles: what each term means

The short answer: related files, different jobs

The two terms overlap in everyday use, which is why the question keeps returning. In a broad sense, both put synchronized text on a screen. In a stricter sense, captions are built for viewers who cannot hear the audio, while subtitles are built for viewers who can hear it but need another language. That difference changes what goes into the file, not just what you call it.

A practical way to decide is to ask who needs the text and why. If the answer is a Deaf or hard-of-hearing viewer who needs the dialogue, speaker changes and important sounds, you are captioning. If the answer is a viewer who can hear the scene but does not speak the language, you are subtitling. Many projects need both, and the same WebVTT or SRT container can hold either version.

Terminology also changes across markets. In the United States, the word captions usually means the accessibility track, while in parts of Europe subtitles for the deaf and hard of hearing is the common phrase. A client may ask for subtitles and mean either version. Confirm the audience, the required content and the file format in writing before the work begins; that short exchange prevents a delivery that technically opens but misses the brief.

What closed captions include that dialogue-only subtitles often do not

Captions carry the dialogue, but they also identify who is speaking and note non-speech information that matters to the story. A door slamming, a phone buzzing, laughter or a piece of music can change how a scene reads. The W3C definition describes captions as a synchronized alternative for both speech and non-speech audio information needed to understand the media. That is a higher bar than transcribing words alone.

Dialogue-only subtitles usually leave those sounds out because the audience can already hear them. A translated subtitle track may also simplify cultural references or condense fast speech to fit the reading speed of the target language. Neither approach is wrong; they serve different audiences. The mistake is delivering a dialogue-only file to viewers who need captions, then assuming the accessibility work is finished.

Open vs closed captions: who controls visibility

Open captions are part of the picture. They are rendered into the video frames, so they cannot be turned off or restyled by the viewer. That makes them reliable on platforms that do not support caption tracks, and it is why social videos often use burned-in text. The trade-off is control: viewers who do not want captions cannot hide them, and the text cannot be edited without re-exporting the video.

Closed captions live in a separate track that the player can show or hide. The viewer can usually change the size, colour or position, and the file remains searchable and editable. Closed captions are the better default for a website, a streaming service or any player with a caption menu. Open captions are a fallback for distribution channels that ignore sidecar files, not a replacement for a proper track when one is supported.

Player support is the deciding factor for this track. HTML5 video uses the track element and WebVTT, and the browser exposes a caption menu when the track is present. Some social players do not offer a visible toggle at all, which is why creators fall back to open captions. Test the actual embed rather than assuming that a file upload will produce a menu.

SDH subtitles and same-language captions

SDH stands for subtitles for Deaf and hard-of-hearing viewers. An SDH file is usually in the same language as the audio and includes speaker labels, meaningful sound descriptions and sometimes music cues. In that respect it behaves like a caption track even when the platform calls it a subtitle. The acronym is common in broadcast and streaming workflows, especially in Europe.

Terminology varies by region. Some countries use subtitles for both same-language and translated text, and distinguish them as intralingual and interlingual. Others reserve captions for the accessibility version and subtitles for translation. Do not rely on the label alone. Open the file and check whether it identifies speakers and describes important sounds; that tells you which audience it can actually serve.

Translated subtitles and language access

Translated subtitles are a language-access tool, not a substitute for captions. They help a viewer who can hear the original audio follow dialogue in another language, but they often omit sound descriptions because the viewer can hear the sound. The W3C guidance makes this distinction explicit: captions are needed for accessibility, while subtitles in another language are not directly an accessibility accommodation.

Translation also changes timing decisions. A target language may need more characters to express the same idea, which pushes against reading speed and the two-line limit. A good workflow translates the meaning, then re-times and re-breaks the lines for the target audience rather than copying the source cue boundaries. Forced narrative captions, which translate only on-screen text or foreign dialogue, are a third case with their own rules.

Burned-in, sidecar and platform caption tracks

A sidecar file is a separate subtitle file such as SRT or WebVTT that travels with the video. It is easy to edit, easy to search and easy to replace without touching the picture. A platform caption track is similar in spirit but lives inside the hosting service; you upload or type the text, and the player exposes it through its own menu. Both keep the text separate from the video frames.

Burned-in text is already part of the image, so every viewer sees it. That can be useful for a short social clip where the platform ignores caption files, but it is a poor master copy. Keep an editable sidecar as the source of truth, then burn a copy only for a destination that requires it. If you need to compare container choices, our SRT vs VTT guide covers the file-level differences.

Which one should you deliver? A comparison table

Start with the audience and the distribution channel. A public website with an HTML5 player usually needs a closed WebVTT track. A broadcast or streaming delivery may require a specific sidecar format and an SDH version. A social clip may need burned-in text because the platform's caption support is limited or inconsistent. The label matters less than whether the viewer can actually read the right information.

When you need both accessibility and translation, produce two files rather than compromising on one. The caption file carries speaker IDs and sounds; the translated subtitle file carries the target-language dialogue and follows its own reading-speed limits. Name the files clearly and test each one in the player. A single file that tries to do both jobs often does neither well.

Keep the master files separate from the delivery copies. Name them with the language, the version and the audience, for example en-captions and fr-subtitles, so nobody uploads the wrong track. After upload, watch the first minute, a dense middle section and the final cue on a phone as well as a desktop. Captions that work in a desktop preview can still collide with interface elements or disappear behind a control on a smaller screen.

Accessibility, WCAG and the limits of legal shorthand

WCAG 2.2 Success Criterion 1.2.2 requires captions for prerecorded audio in synchronized media, with an exception for media that is already a text alternative and is clearly labelled. Success Criterion 1.2.4 covers live audio at Level AA. Those are conformance requirements in a technical standard; they are not, by themselves, a statement of every law in every country.

Legal requirements vary, and this article is not legal advice. What the guidance does make clear is that captions need to carry more than dialogue when sounds matter. The W3C WAI captions page also notes that automatic captions are not sufficient unless they are fully accurate, which is why a review pass matters. If accessibility is the goal, start with the accessibility guide and then choose the container.