SDH, closed captions, and subtitles: what each track carries

💡 Closed captions (SCC/SMPTE-TT) embed dialogue, sound effects, speaker IDs, and music notes inside the broadcast signal. SDH subtitles carry the same content as a separate, player-toggleable text track. Plain subtitles carry dialogue only. The W3C HTML spec captures this: kind="captions" is for deaf viewers, kind="subtitles" is for language translation.

What each track type carries, side by side

The three terms share enough surface area that delivery errors happen regularly. A distributor requests "SDH" and receives a clean dialogue-only SRT file. Or a broadcaster asks for "closed captions" and receives a VTT file that looks correct but omits the broadcast-encoded channel data. The W3C HTML Living Standard gives the sharpest definition I use as a reference: a kind="captions" track is "transcription or translation of the dialogue, sound effects, relevant musical cues, and other relevant audio information, suitable for when sound is unavailable." A kind="subtitles" track is "transcription or translation of the dialogue, suitable for when the sound is available but not understood."

Track type	Dialogue	Sound effects	Speaker IDs	Music cues	Toggle	Typical formats
Closed captions	Yes	Yes	Yes	Yes	On/off in decoder	SCC, SMPTE-TT, MCC
SDH subtitles	Yes	Yes	Yes	Yes	On/off in player	SRT, TTML/IMSC, VTT
Standard subtitles	Yes	No	No	No	On/off in player	SRT, VTT, TTML
Open (burned-in)	Yes	Yes (typically)	Optional	Optional	Always on	None - rendered into video

SDH and standard subtitles often use identical file formats, both typically SRT. The format alone does not reveal which you have. A quick check: does the file contain any [sound effect] tags or speaker identifiers? If not, it is a standard subtitle file regardless of what the contract says.

Which file format goes with which track type?

For US broadcast delivery I use SCC (Scenarist Closed Captions) for a CEA-608 deliverable. SCC is a Latin-character format: it cannot encode Vietnamese diacritics, Chinese characters, or any CJK text. Closed captions for US broadcast are English captions; other languages go in a separate subtitle track, not in CEA-608.

For a CEA-708 deliverable (digital cable and DTV), I use SMPTE-TT (ST 2052-1 XML) rather than a hand-built MCC file. Subtitle Edit's MCC export produces a 708 service layer that caption-inspector cannot decode - a QC failure I encountered in a real delivery. SMPTE-TT is the more reliable open-source path for a 708-compatible file.

For streaming (Netflix, web): SRT or TTML/IMSC for SDH; the same formats work for standard subtitles too. The HTML <track> element makes the distinction explicit in code:

<!-- Closed captions for English deaf/HOH viewers -->
<track kind="captions" src="en-cc.vtt" srclang="en" label="English CC" default>

<!-- SDH for Vietnamese deaf/HOH viewers: dialogue + sound events -->
<track kind="captions" src="vi-sdh.vtt" srclang="vi" label="Tiếng Việt SDH">

<!-- Standard subtitles for hearing Vietnamese viewers -->
<track kind="subtitles" src="vi-subs.vtt" srclang="vi" label="Tiếng Việt">

• kind="captions": signals deaf/HOH use; browsers may auto-enable this in muted or no-audio contexts
• kind="subtitles": signals language aid; does not auto-enable in no-audio contexts
• Both can use VTT or SRT as the file format - the kind attribute is the technical distinction, not the file extension

What does "closed" actually mean?

The term comes from 1970s US broadcast: the caption text was "closed" inside the vertical blanking interval of the TV signal, invisible until a decoder activated it. The opposite, "open captions," are rendered into the video itself (burned in) and always visible. In 2026, the distinction survives:

• Closed captions: off by default, activated by the viewer or forced by the player
• Open captions: always on, not removable - common in short-form social video and any environment where caption-rendering infrastructure cannot be guaranteed
• SDH subtitles: technically "closed" in behaviour (the viewer toggles them), but not called "closed captions" because they are not CEA-608/708-encoded

WCAG 1.2.2 requires that captions "are provided" with the content - satisfied by either toggleable captions or burned-in captions. Toggleable captions are generally preferred because they can be resized, repositioned, and reflowed on low-vision devices; burned-in captions cannot.

Which law or standard requires which track type?

Knowing the applicable rule helps you pick the right deliverable before production, not after a compliance flag.

• FCC (47 CFR Part 79): closed captions required on English-language US broadcast and cable programming, and on online video that was previously on TV (CVAA, post-2010)
• ADA / Section 508: captions required for government and federally-funded video; the applicable definition is the WCAG one - full sound-event coverage, not dialogue-only subtitles
• WCAG 1.2.2 (Level A): captions required for all prerecorded audio in synchronized media; SDH satisfies this requirement; standard subtitles do not because they omit non-speech audio information
• EAA 2025 (European Accessibility Act): requires subtitles for the deaf and hard of hearing for audiovisual media services; the SDH content requirement applies

Standard subtitle tracks satisfy a different requirement: making dialogue understandable to viewers who do not speak the source language. They do not substitute for SDH or closed captions where accessibility law applies.

What to handle yourself vs when specialist delivery matters

Building an SDH track in Subtitle Edit and exporting to SRT is fully doable without broadcast engineering background. The most common content mistake I see: a distributor requests "Vietnamese SDH" and receives a dialogue-only translation. Both are valid SRT files with matching timing; the difference is entirely in the content.

My process for a Vietnamese SDH track: I start from the English SDH file (which already carries [SOUND EFFECT] tags, speaker IDs, and music markers), translate the dialogue, and keep all non-dialogue events intact. A plain Vietnamese translation of the English subtitle file loses every non-dialogue event in the process. The Subtitle Edit SDH filter (Tools menu, then SDH) shows which events carry non-dialogue tags - running it before delivery is a useful final check.

The point where format expertise changes the outcome: US broadcast and regulatory submission. Producing a clean SCC or SMPTE-TT file means understanding 29.97 drop-frame timecode, CEA-608 column limits (32 per row, 15 rows), and using caption-inspector to decode the output and confirm the 608/708 data is clean. A valid SRT file with correct SDH content is not a valid broadcast deliverable - the encoded format is what 47 CFR Part 79 requires.

For English closed-caption and SDH delivery on US streaming and broadcast titles, I cover both the content and the format. For Vietnamese subtitle tracks alongside an English SDH track, the subtitle translation service translates dialogue while keeping timing and non-dialogue events intact.

FAQ

My client asked for "closed captions." Do I deliver SCC, SMPTE-TT, or VTT?

Ask which distribution platform and what frame rate. For FCC-regulated US broadcast: SCC (CEA-608) at 29.97 drop-frame, or SMPTE-TT for a 708-capable deliverable. For Netflix or most streaming platforms: TTML/IMSC or SRT. "Closed captions" covers both the content type (dialogue plus sound events) and the broadcast format (CEA-608/708); which file to deliver depends on the distribution target.

Is a VTT file with kind="captions" the same as broadcast closed captions?

In content, yes: both carry dialogue, sound effects, and speaker IDs. For US broadcast legally and technically, no. The FCC requires CEA-608/708-encoded data in SCC or SMPTE-TT format; a VTT file does not satisfy that requirement. A VTT kind="captions" satisfies WCAG 1.2.2 for web video but is not a broadcast-grade deliverable.

What is the difference between "HI subtitles" and SDH?

They are the same concept under different names. "HI" (Hearing Impaired) subtitles is the European broadcaster term; "SDH" (Subtitles for the Deaf and Hard of Hearing) is the US and streaming platform term. Both carry dialogue, sound effects, speaker IDs, and music. Minor formatting conventions differ by region but the content requirement is identical.

What character sets does CEA-608 support, and how does that affect delivery?

CEA-608 is a Latin-character standard. It covers English, Spanish, French, and other Western European scripts via extended character packs. Languages that use diacritics or non-Latin scripts require a Unicode-capable format - SRT, VTT, and TTML all handle this correctly. That applies to Vietnamese diacritics and to Chinese characters alike. The correct delivery path for those languages: a separate SRT or TTML track alongside the English CEA-608 file, not encoded inside the CEA-608 data stream.

Does every subtitle file need to be SDH to satisfy accessibility requirements?

No. The SDH requirement applies when providing a captioning equivalent for deaf or hard-of-hearing viewers in a given language. A French subtitle track for hearing viewers who do not speak French does not need SDH content. If you also want the French track to serve Deaf francophone viewers, it needs sound effects and speaker IDs too. Netflix requires a separate SDH track for the primary language of every title in its library.

Official Sources

• HTML Living Standard: Text Track Kinds (WHATWG) - official definitions of kind="captions" vs kind="subtitles". Verified Oct 2026.
• WCAG 2.1 Understanding 1.2.2: Captions (Prerecorded) - definition of captions including sound effects and speaker IDs; Level A compliance. Verified Oct 2026.
• WCAG 2.2 Success Criterion 1.2.2 - current captions requirement for prerecorded media. Verified Oct 2026.
• 47 CFR Part 79 (eCFR) - FCC closed captioning regulations for US broadcast and CVAA online video. Verified Oct 2026.