Subtitles vs Captions: Open vs Closed, Explained

Subtitles translate dialogue for viewers who can hear but don't speak the language. Captions carry speech plus non-speech audio for deaf and hard-of-hearing viewers. Open captions are burned into the picture and cannot be switched off. Closed captions ship as a separate file, like an SRT, that the player toggles on.

The two words get used interchangeably most days and nothing breaks. They start mattering when you decide whether the text lives inside your pixels or beside them in a file.

What is the difference between subtitles and captions?

The W3C's Web Accessibility Initiative splits them by audience. Captions are "a text version of the speech and non-speech audio information needed to understand the content". Subtitles, in the same guidance, are for "spoken audio translated into another language" — and WAI states the consequence directly: "Captions are needed for accessibility, whereas subtitles in other languages are not directly an accessibility accommodation."

The field test is non-speech audio. [door slams] and [laughs] belong in captions and are clutter in a translation subtitle, which assumes the viewer heard the door perfectly well and simply doesn't speak the language.

Take a podcast clip where the guest's laugh lands the joke. The Spanish subtitle carries the sentence. The English caption carries the sentence and [laughs]. Same eight seconds, two deliverables, two different people served.

One regional wrinkle, worth knowing before a client call goes sideways: WCAG's explainer for captions notes that "In some countries, captions are called subtitles". If a brief says "subtitles", ask which meaning.

What are open captions vs closed captions?

This is the axis creators actually argue about, and it has nothing to do with language.

WAI again: "Most are 'closed captions' that can be hidden or shown by people watching the video. They can be 'open captions' that are always displayed and cannot be turned off." WCAG's understanding document is blunter — "Open Captions are any captions that cannot be turned off. For example, if the captions are visual equivalent images of text embedded in video."

Open captions are burned in: the text is part of the frame. It survives a repost, a screen recording, a download, and a platform with no caption button.

Closed captions are a sidecar file. YouTube describes the format plainly: "A subtitle or closed caption file contains the text of what is said in the video. It also contains time codes for when each line of text should be displayed." SubRip (.srt) is on its supported list, with a caveat — for basic files, "Only basic versions of these files are supported. No style info (markup) is recognized." Your font, your colour, your word-by-word timing: none of it travels in a plain SRT.

The viewer also has to find the button: on YouTube's Android app you "Tap the video player once to show options, then, tap Closed captions", and "If you don't see Closed captions, then Closed Captions (CC) aren't available for this video." Closed means optional, and optional means a share of your audience never turns it on.

Should you burn captions in or ship an SRT file?

Scenario	Burned-in (open)	Sidecar file (closed)
Short-form vertical clip	Yes	Yes, where the platform accepts one
Long-form YouTube upload	Usually no	Yes
Second-language translation	One burn per language, or skip	Yes — one file per language
Client or broadcaster delivery	Ask first	Usually required
Handoff to an editor	No	Yes — SRT into the timeline
Viewer who needs bigger text	You can't help them	Their player settings win

The short version: burn in when you cannot trust the player, ship a file when you can. On a vertical clip that will be reposted and screen-recorded, the burn is the durable copy. On your own long-form upload, where the CC button works and the viewer's font-size preferences are respected, the file is the kinder copy. Translation is its own decision rather than a reflex — we weigh it up in should you translate your YouTube Shorts.

Do burned-in captions still count as accessible?

Yes, as far as the standard goes. WCAG success criterion 1.2.2 reads: "Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such." Nothing in it requires the captions to be switchable. Open captions satisfy it.

What a burn costs is control. A viewer who reads slowly cannot enlarge your text. A viewer who finds moving captions uncomfortable cannot turn them off. The Described and Captioned Media Program puts the stakes plainly: "Captioning is the key to opening up a world of information for persons with hearing loss or literacy needs" — and a key should not depend on whether your font size suited a stranger's eyes.

If you make video for a public institution, there is also a date. The U.S. Department of Justice's 2024 web rule requires state and local government web content and mobile apps to meet WCAG 2.1 Level AA, with compliance due 26 April 2027 for entities serving populations of 50,000 or more and 26 April 2028 for smaller entities and special districts. A lecture clip published by a state or local government body falls under that, and a burn alone is a thin answer when the file costs nothing.

Why does muted autoplay change the answer for short-form?

Because on a vertical feed, the platform's caption layer is a maybe and your burn is a certainty.

TikTok's auto captions are creator-enabled — creators turn them on in the editing page after uploading or recording a video — and viewer-disabled: "In the event a viewer wants to turn them off they can do so by opening the share panel, tapping the captions button, and setting captions to off". YouTube generates automatic captions on long-form videos and Shorts, and warns that "automatic captions might misrepresent the spoken content due to mispronunciations, accents, dialects, or background noise", adding: "You should always review automatic captions and edit any parts that haven't been properly transcribed."

So the platform layer can be switched off, sits where the platform wants it, and may get your product name wrong. The burned layer is the one you control — the whole argument for word-timed burned captions on muted autoplay.

What should you check before you publish captions?

• Write for the ear that can't hear. Speaker labels when two voices trade lines, [music] when the music is carrying the meaning.
• Read the burn at phone size before you ship. Thumb-sized is the real test, not a 27-inch monitor.
• Preview the burn inside each app before you commit to a caption position. Interface overlays differ per platform.
• Export the SRT even when you burned in. Your editor, your translator and your website player all want it.
• Check every machine transcript for names, jargon and product spellings. YouTube says to, and it is right.
• One language per burn. Multi-language belongs in files unless you are genuinely cutting a version per market.

Everpop does both halves by default: word-by-word burned captions with six curated fonts under the SIL Open Font License on every plan, plus an editor handoff export in FCPXML, EDL and SRT — so the sidecar file exists whether or not you burned anything in. Nothing publishes until you approve it, and every clip gets three free re-renders when a line breaks in the wrong place. Clip counts per video vary by plan; those are on the pricing page.

Burn for the feed, keep the file for everyone else, and stop treating the two words as synonyms in the one conversation where the difference is the job.