Scroll through the subtitle menu on almost any streaming title and you will find three options that look interchangeable. English. English [CC]. English SDH. Most viewers pick one at random, notice the wording is not quite what they expected, and carry on watching. The distinction is not cosmetic. SDH subtitles were built to do a job the other two files were never designed for, and choosing the wrong one is one of the quieter ways a video project wastes money.
What SDH subtitles actually carry
SDH stands for subtitles for the deaf and hard of hearing. The label describes an audience rather than a technology, which is the source of most of the confusion. A standard subtitle track transcribes dialogue and nothing else, on the assumption that the viewer can hear the door slam, the phone buzz and the strings coming up under the last scene. An SDH track assumes none of that. It adds speaker labels when two voices overlap offscreen, bracketed descriptions of sound effects that carry plot information, and notes about music when the music is doing narrative work rather than sitting in the background.
The result reads differently on screen. Where a plain subtitle shows one line of dialogue, an SDH file might show the speaker name, the line, and a bracketed cue telling you a car is pulling up outside. Done with restraint it is almost invisible. Done badly it floods a tense scene with brackets and turns the frame into an inventory of noises.
Why the format exists at all
Broadcast television solved this problem decades ago with closed captions, which travel in a dedicated data channel inside the signal. A television or set top box decodes that channel and paints the text on screen. The system works beautifully on a broadcast feed and not at all anywhere else. DVDs, Blu-rays and the first generation of streaming players had no caption channel to decode, so the accessibility information had to be moved into an ordinary subtitle file instead. SDH is what came out of that migration: caption content delivered through subtitle plumbing.
That history explains the awkward three-way split viewers still see. Closed captions and SDH overlap heavily in what they communicate and differ mainly in how they are encoded, how they are styled and who controls their position on the screen. Most arguments about closed captioning vs subtitles go sideways because the people having them are comparing a delivery format to an audience.
Three deliverables that are easy to confuse
It helps to separate the three by the question each one answers. A translated subtitle file answers "what are they saying, in my language". A closed caption track answers "what can I not hear, in the original language, through the broadcast pipeline". An SDH file answers that same second question, but as a subtitle asset that any modern player can render. The W3C guidance on captions and subtitles as accessibility features makes the same split, and it is worth reading before commissioning any of the three, because vendors price them very differently.
Anyone who has wondered what are subtitles supposed to include has effectively been asking which of these three files they are looking at. The menu label rarely makes it obvious, and platforms are inconsistent about how they name the options.
SDH subtitles are not captions with extra lines; they carry sound design, speaker identity and tone that a hearing viewer gets for free. Teams that treat this as a specialism rather than a checkbox usually end up commissioning proper subtitling services instead of auto-generating and hoping. The difference shows up in the complaints they never receive.
What this means if you publish video
If your content goes out to a general audience in one language, a clean SDH track will usually serve you better than a plain subtitle file, because it covers hearing viewers who watch on mute in public and deaf viewers who need the sound design described. Silent autoplay has quietly made captions a mainstream feature rather than an accommodation, and the numbers on watch time reflect that. PoliLingua has written a useful overview of the case for close captioning that lays out the commercial side of the argument rather than only the compliance one.
If your content crosses languages, the picture gets more complicated, because the SDH conventions of one market do not transfer neatly to another. The way subtitles on Netflix and comparable services are produced shows how much of this is process rather than translation: a single source transcript, timed once, then adapted per territory with different reading speed limits and different rules about how much non-dialogue information belongs on screen.
Getting it right without inflating the schedule
The practical advice is dull and works. Start from an accurate transcript with speaker attribution already in it, because retrofitting speaker labels later is where most of the cost hides. Time the file once, properly, and treat the timing as the master asset. Keep sound effect cues to the ones a viewer would miss the plot without, not every creak on the soundtrack. Respect reading speed rather than fidelity to the script, since a line nobody can finish reading is worse than a lightly condensed one.
Automatic speech recognition will get you a first draft in minutes and it is genuinely good now, but it does not know which sounds matter. That judgement is still the human part of the job, and it is the part that separates an SDH file people actually leave switched on from one they turn off after two scenes.
The three-item menu is not going away, and neither is the confusion around it. But once you know that SDH is the accessibility version of a subtitle rather than a slightly wordier translation, the choice in front of you gets much simpler, whether you are the person watching or the person paying for the file.