A localization manager gets a note back from a streaming partner: the delivery needs English SDH, not closed captions. She pulls up the caption file the team already has, checks the format, and realizes it won’t work as is. Same dialogue. Same speaker labels. Wrong delivery format entirely.
This mix-up happens constantly, and it’s understandable. SDH and closed captions look nearly identical to a viewer. Both show dialogue, speaker names, and sound effects like [door slams] or [phone rings]. But underneath that shared purpose, they’re built differently, delivered differently, and required by different rules depending on where the content airs. Getting this wrong doesn’t just create rework. It can delay a delivery deadline or fail a platform’s conformance check entirely.
What Closed Captions (CC) Actually Are
Closed captions were built for broadcast television, and that history still shapes how they work today. In the US, closed captions are required by law on public broadcasts under FCC regulations, historically delivered through the CEA-608 standard (often called Line 21 captions) for analog signals, and CEA-708 for digital broadcast.
Technically, closed captions aren’t a subtitle file layered on top of video. They’re encoded as a stream of commands and control codes embedded in or alongside the broadcast signal itself, delivered in formats like SCC or MCC. That encoding is what allows captions to be positioned near the speaker on screen, which helps viewers follow overlapping dialogue or identify who’s talking without a separate label.
Closed captions can be toggled on or off by the viewer, which is the “closed” in the name. Traditionally, they appear as white text on a black band, though many modern displays now allow some customization. One practical limitation worth knowing: closed captions typically cap out around 32 characters per line, a legacy constraint from broadcast-era encoding.
What SDH (Subtitles for the Deaf and Hard of Hearing) Actually Are
SDH exists because most modern delivery formats never supported traditional closed caption tracks in the first place. Streaming platforms, Blu-ray discs, and HDMI connections generally can’t carry embedded CEA-608/708 caption streams, so SDH fills that gap by delivering the same type of accessibility content through a standard subtitle track instead.
Functionally, SDH does almost everything closed captions do. It includes dialogue, speaker identification, sound effects, and music cues, all built for a viewer who can’t hear the audio rather than one who simply doesn’t understand the language. The difference is entirely in the delivery mechanism. SDH is rendered as a subtitle file, commonly SRT, WebVTT, TTML, or IMSC, or in some cases as a bitmap image track rather than encoded control codes.
Because it inherits subtitle-style flexibility, SDH generally allows more room for styling: proportional fonts, custom colors, and a higher character limit, typically around 42 characters per line compared to closed captions’ 32. SDH text is also usually centered in the bottom third of the screen rather than repositioned near each speaker, and unlike closed captions, SDH can be translated into other languages while retaining its full accessibility content.
The Core Differences, Side by Side
| Feature | Closed Captions (CC) | SDH |
| Delivery format | Encoded stream (CEA-608/708), SCC/MCC | Subtitle track (SRT, WebVTT, TTML, IMSC) |
| Typical use case | US broadcast television | Streaming platforms, Blu-ray, HDMI-based playback |
| Regulatory driver | FCC requirement for public broadcast | Platform style guides, ADA/WCAG, EAA compliance |
| Character limit | Around 32 characters per line | Around 42 characters per line |
| On-screen positioning | Repositioned near the speaker | Typically centered, bottom third |
| Styling flexibility | Limited, historically white text on black | Proportional fonts, custom color and size |
| Can be translated | No | Yes |
| Common file types | SCC, MCC, embedded 608/708 | SRT, VTT, TTML, DFXP, bitmap tracks |
Where Regular Subtitles Fit Into This Picture
It’s worth separating SDH from plain subtitles, since the two get confused just as often. Regular subtitles assume the viewer can hear the audio just fine and simply need the dialogue translated or transcribed, usually for a different spoken language. They skip sound effects, music cues, and speaker labels entirely, because that information isn’t the point. SDH, by contrast, assumes the viewer can’t hear the audio at all and needs the full picture: who’s speaking, what’s being said, and what’s happening in the background.
Open captions deserve a mention too, though they’re a delivery choice rather than a content type. Open captions are burned permanently into the video frame, with no toggle and no separate track. You can burn in either standard subtitles or SDH-style content; what makes it “open” is simply that the viewer can’t turn it off.
Why This Distinction Matters More in 2026
Compliance expectations around accessible video keep tightening, and the format you choose isn’t just a technical preference anymore.
In the US, closed captions remain a hard FCC requirement for broadcast television. Separately, the Department of Justice’s ADA Title II rule has set WCAG 2.1 Level AA as the binding accessibility standard for state and local government video content, with compliance deadlines arriving in 2027 and 2028 depending on entity size. In the EU, the European Accessibility Act has applied since mid-2025, adding another layer of obligation for organizations distributing content across European markets.
Streaming platforms add their own layer on top of all this. Major services typically require SDH rather than legacy broadcast captions, simply because their delivery infrastructure was never built around CEA-608/708 encoding. A delivery that meets broadcast compliance can still get rejected by a streaming partner’s conformance check if it arrives in the wrong format.
A Practical Scenario: One Piece of Content, Two Deliveries
Consider a documentary that airs on broadcast television and later gets licensed to a streaming platform. The broadcast delivery needs FCC-compliant closed captions, encoded to CEA-708 standards, positioned near each speaker, and logged for compliance purposes.
The streaming delivery needs something different: English SDH as a subtitle track, likely alongside translated subtitle tracks for international markets, styled according to the platform’s own specification rather than broadcast conventions. Same underlying dialogue and sound information, two entirely different technical deliveries, each with its own conformance requirements.
Teams that treat these as interchangeable formats often discover the problem late, during a platform’s QC rejection, which turns what should be a one-time captioning job into a rework cycle against a delivery deadline.
Checklist for Choosing the Right Format
- Confirm the destination platform first. Broadcast, streaming, disc, or web each has different requirements.
- Check whether the destination supports embedded CEA-608/708 tracks, or requires a subtitle-based format instead.
- Verify character-per-line limits against the platform’s own style guide, not just the general CC or SDH standard.
- Decide early if translation is needed. SDH can be translated; closed captions typically aren’t.
- Confirm positioning requirements. Broadcast often expects speaker-adjacent placement; streaming usually expects centered, bottom-third text.
- Build compliance logging into the workflow if the content is broadcast-bound, since regulators expect a verifiable record.
Common Objections, Answered
“Can’t we just use the same caption file for both broadcast and streaming?” Not reliably. The underlying text can be similar, but the format, character limits, and encoding are different enough that most platforms will reject a mismatched delivery during conformance review.
“Isn’t SDH just a lower-quality version of closed captions?” No. SDH carries the same accessibility content as closed captions, sometimes with more room per line due to the higher character limit. The difference is technical delivery, not quality.
“Do we really need separate workflows for CC and SDH?” Not necessarily separate workflows, but definitely separate output steps. Many teams generate an accurate master transcript once, then export it into whichever format, CC or SDH, the destination requires.
How Digital Nirvana Supports Multi-Format Captioning Workflows
Getting this right at scale means building a workflow that produces both formats from a single, accurate source rather than recreating captions from scratch for every delivery. TranceIQ handles cloud transcription, subtitle generation, and caption conformance across broadcast and OTT delivery, generating output in the specific format each destination requires. For high-volume or live content where accuracy under deadline pressure matters most, Media Enrichment adds managed, human-assisted review to catch the details that automated captioning alone can miss.
On the broadcast side, MonitorIQ tracks closed caption compliance, including CC608 and CC708 standards, so teams have a verifiable record for FCC reporting. And because caption text is genuinely useful beyond accessibility alone, MetadataIQ indexes that same transcript data to make archived content searchable by dialogue, not just by title or air date. The speech-to-text models behind that accurate master transcript draw on the same AI/ML microservices used across Digital Nirvana’s broader platform, with Managed AI review supporting accuracy on the low-confidence segments most likely to trip up an automated caption pass.
Why Getting This Right Protects More Than Compliance
Choosing the correct format isn’t only about passing a platform’s QC check. Accurate, properly formatted captions and subtitles genuinely determine whether deaf and hard-of-hearing audiences, and international viewers, can access content at all. A rejected delivery costs a team time. A poorly executed caption format costs a viewer their ability to follow the content in the first place.
Digital Nirvana’s work across captioning, compliance, and searchable metadata, reflected in its documented customer outcomes and broader platform, consistently treats accessibility formatting as a core production requirement rather than a final checklist item, because for a meaningful share of the audience, it’s the only way the content is accessible at all.
FAQ
Is SDH the same thing as closed captions? Functionally, yes, both include dialogue, speaker labels, sound effects, and music cues. Technically, no, closed captions are an encoded broadcast track while SDH is delivered as a subtitle file.
Why do streaming platforms use SDH instead of closed captions? Most streaming delivery infrastructure, along with Blu-ray and HDMI connections, was never built to carry embedded CEA-608/708 caption streams, so SDH delivers the same accessibility content through a subtitle track instead.
Can closed captions be translated into other languages? Generally no. Closed captions are built for same-language accessibility. SDH, because it’s delivered as a subtitle file, can be translated while still retaining its full accessibility content.
Conclusion
SDH and closed captions solve the same underlying problem, making content accessible to viewers who can’t hear it, through two genuinely different technical paths. Knowing which one a destination requires, and why, saves a rejected delivery, a missed deadline, or a failed compliance check. The teams that handle this well aren’t necessarily doing more work. They’re building a workflow that generates an accurate master transcript once and exports it correctly for wherever the content is headed next.
Key Takeaways
- Closed captions are an encoded broadcast track (CEA-608/708); SDH is a subtitle-format file built for platforms that don’t support legacy CC tracks
- Both carry the same accessibility content, dialogue, speaker labels, sound effects, and music cues, unlike plain subtitles, which assume the viewer can hear
- SDH allows more characters per line and can be translated; closed captions generally cannot
- Broadcast and streaming deliveries for the same content often require both formats, generated from one accurate source transcript
- Regulatory requirements (FCC, ADA Title II, the EU’s European Accessibility Act) increasingly shape which format is mandatory, not just which one a platform prefers
