Closed captions for
CTV advertising,
in plain language.

Short answer: the IAB's VAST 4.1 spec supports sidecar caption files (text/srt, text/vtt, application/ttml+xml) inside the <ClosedCaptionFile> element. Some CTV platforms accept those files. Others (Hulu) require captions burned into the master. Others (DV360 for non-YouTube placements) do not carry sidecars at all. Captioning on CTV ads is a per-platform negotiation, not a spec-sheet checkbox.

Connected TV (CTV) advertising delivery sits in a gap between broadcast (FCC-regulated under 47 CFR § 79.1, captioning required) and online programming (FCC-regulated under § 79.4 for full-length programs, captioning required). Commercial spots fall outside both rules. What drives captioning on CTV is brand procurement, agency QA, sound-off viewer behavior, and ADA Title III exposure on the brand's own .com properties.

Are closed captions legally required on a CTV ad?

Not by federal law in the United States. 47 CFR § 79.4 covers IP-delivered "full-length video programming" that previously aired on TV with captions — not ads. § 79.1 applies to broadcast TV programming but excludes interstitial material and ads of 10 minutes or less. Most :15, :30, :60, and :90 commercial spots sit outside both rules.

What does require captioning on a CTV ad is private contracting. Brand procurement contracts at most national advertisers reference WCAG 2.1 Level AA conformance, which includes criterion 1.2.2 requiring synchronized captions on all prerecorded media. Sound-off autoplay also matters — Amazon explicitly tells advertisers their streaming TV ads must work muted, which is functionally a caption requirement. The combined effect: federal law is silent, every other layer of the system asks for captions, so captions get added.

What does the IAB VAST 4.x spec say about captions?

VAST 4.1 (2018) added the <ClosedCaptionFile> element, a child of <MediaFiles> that references a sidecar caption file alongside the video URL. The element takes type (MIME) and language attributes. The IAB's own sample VAST tag (Closed_Caption_Test.xml) demonstrates four files attached to one ad in four MIME/language combinations: SRT English, SRT French, WebVTT Traditional Chinese, TTML Simplified Chinese.

A common misconception worth correcting: <ClosedCaptionFile> did not ship in VAST 4.0. The IAB's own samples directory shelves it under "VAST 4.1 Samples," and the change is called out in the VAST 4.x Benefits Overview as a 4.1 addition. Vendor blogs that say otherwise are wrong.

VAST also defines an extension for the SCC format via the application/x-scc MIME type in some implementations, but SCC does not appear in the IAB's published sample. SCC is the broadcast handoff format, not the CTV programmatic format. The CTV pattern is VTT or TTML as sidecar; SCC is for the ad-delivery pipeline upstream.

What caption formats does each major CTV platform actually accept?

This is where the spec and reality diverge. Some platforms publish a caption spec on their public ad-specs page. Most do not.

Hulu's published quicksheet (PDF: assets.huluim.com/downloads/hulu_ad_specs_quicksheet.pdf) is the canonical reference. Industry secondary sourcing (Rev, 3Play, Keynes Digital) consistently reports the operative rule: SRT/VTT sidecars are not accepted; captions must be burned into the master. Roku's two public ad-specs pages list codec, bitrate, frame rate, and duration — but do not mention captions, SCC, or WebVTT at all. Samsung Ads DSP's creative-specifications page is similar. For Roku and Samsung, the only authoritative answer is to ask your platform rep, because the public spec is silent.

Why does DV360 reject sidecar caption files?

Google publishes this directly. DV360 Help: "Video creatives don't support closed caption or .SRT files in Display & Video 360. You must add subtitles directly to videos." In practice that means burned-in ("open") captions baked into the master MP4 for any non-YouTube CTV placement bought through DV360.

For YouTube placements specifically (including YouTube TV), captions are handled differently — through the YouTube video's own subtitle track on the hosting channel, not via the DV360 creative. If your CTV media plan includes DV360-served non-YouTube inventory, the bottom line is: burn captions into the master before trafficking, or you won't have captions on those impressions.

How do you ship one creative to five platforms at once?

Two viable patterns. Either author one master with captions burned in — which satisfies Hulu and DV360 non-YouTube but loses the user-toggleable caption track that good UX wants — or author one master plus VTT/TTML sidecars in the VAST tag, accept that Hulu and DV360 will not honor them, and have a separate burn-in master ready for those platforms.

The practical workflow most large agencies have settled on: one off-line master with no captions, one VAST tag carrying a WebVTT sidecar plus a TTML sidecar for the platforms that accept them, and one separate burned-in version for Hulu and DV360. That is three versions of one creative, not one, and that math is part of why CTV media costs run heavier than agencies expect.

VAST 4.1 supports sidecar caption files. Hulu and DV360 do not. CTV captioning is a per-platform negotiation, not a spec-sheet checkbox. — The Slate, reading the published specs

Where do CTV ads go wrong on caption timing?

Timecode origin. Broadcast SCC files traditionally start at 01:00:00:00 (one hour SMPTE drop-frame leader). CTV sidecar VTT, SRT, and TTML start at 00:00:00.000. A file delivered at the wrong origin renders blank or one hour late. This is the most common single failure mode for an agency converting a broadcast SCC to a CTV VTT.

Embedded vs. sidecar. Legacy linear playout reads embedded 608/708 captions inside the MP4. CTV programmatic reads the sidecar referenced in the VAST tag. Hulu burns captions into the picture. Same captions, three different delivery models. Same source caption file, three different output formats.

Multiple language tracks. VAST 4.1 accepts multiple <ClosedCaptionFile> children with different language attributes. Most CTV players honor the language switch; some do not. Validate per-platform before promising a multilingual deliverable on a media plan.

Three things to put on a CTV captioning checklist

1. Get the platform spec sheet for every placement before trafficking. Hulu publishes a PDF; DV360 publishes a help article; Roku and Samsung publish codec/bitrate but not captions. If the spec is silent, ask the platform rep in writing — do not assume the VAST spec carries through.
2. Author one source, export three masters. Post Slate ships VTT/SRT/TTML/SCC from one source; manual workflows author the captions once and export at delivery. Have the VAST tag carry the VTT/TTML, the burned-in master ready for Hulu and DV360 non-YouTube, and SCC for any broadcast pickup of the same creative.
3. Validate timecode origin separately from caption content. Most CTV-delivery validators check that captions are syntactically valid VTT, not that the timecodes line up with the picture. Open the final tag in a player and watch the ad end-to-end with captions on before the trafficker hits go.

Editor's note. Prepared by The Slate, Editorial. Published 11 May 2026. Platform requirements reflect published help-center documentation current as of writing. Hulu burn-in policy is sourced from their published ad-specs quicksheet (PDF). Roku and Samsung Ads DSP do not publish a public caption specification — specific requirements should be confirmed with the platform rep. Not legal advice.