Captions vs Subtitles, Open vs Closed: Two Questions

Four words get used interchangeably and mean four different things: captions, subtitles, open, and closed. Most of the time the muddle costs nothing. It starts costing something when you pick an export format, hand a file to a client with accessibility requirements, or try to work out why a platform will not show the text you uploaded.

The useful part is that there are only two questions underneath all of it, and they are independent of each other.

Question one: what does the text contain?

Subtitles assume you can hear the audio and cannot follow the language. They carry dialogue. That is the whole job.

Captions assume you cannot hear the audio at all. So alongside the dialogue they carry who is speaking when the picture does not say, and the sounds that change what a scene means: a knock at the door, a phone ringing, music that sets a mood. What a caption needs beyond the words covers that pass in detail.

You will also see SDH, subtitles for the deaf and hard of hearing. It is the hybrid: caption-style information delivered through a subtitle-style track, which is what streaming and disc formats tend to use.

Question two: how does the text reach the screen?

Open means the words are part of the picture. They were rendered into the frames, so every viewer sees them and nobody can switch them off.

Closed means the words live in a separate file that the player draws on top. The viewer decides whether to show them. That is what the CC button toggles, and it is where the name comes from: closed as in hidden until someone opens it.

Which one you want is covered in hardcoded versus soft subtitles. The short version is that open captions survive autoplay in a muted feed and closed captions survive everything else, so publishing both is often the honest answer.

The two questions do not answer each other

This is where the confusion actually lives, and it is worth stating plainly: whether text is open or closed says nothing about how it was written.

A closed caption track can be typed by a professional over an hour, or generated by speech recognition in four seconds. Both arrive as a file the viewer toggles. So "are closed captions automatically generated?" has no single answer: some are, some are not, and you cannot tell which by looking at the CC button.

The same holds the other way. Open captions burnt into a Reel are usually machine-generated and then styled, but a broadcaster burning subtitles into a news package is working from a human transcript. Delivery and authorship are separate axes.

Where automatic captions come from, and what they miss

Automatic captions are produced by speech recognition. YouTube generates them for most uploads without being asked, and every major platform now offers something similar.

They are genuinely useful and they are a draft. Recognition is weakest exactly where meaning concentrates: names, places, technical terms, and any language it was not tuned for. It also transcribes speech and nothing else, so an automatic track is a subtitle in caption clothing. Nothing in it tells a deaf viewer that someone knocked.

Which is the practical reason to treat the automatic version as a starting point rather than an output. Read it, fix the names, add what a transcript cannot know, and keep the file.

What to do with the distinction

When a platform asks for a subtitle file, it wants a separate track: SRT for most uploads, WebVTT for web players. When a client asks for captions in an accessibility context, they mean the content standard, not the delivery, and dialogue alone will not satisfy it.

Keep the timed file whatever you do. Burnt-in text cannot be corrected, translated, or read by assistive software, and rebuilding a caption track from a finished video is work you already did once.

To produce one, start in the caption generator, review the wording, then export SRT or VTT. To translate an existing track rather than re-transcribe, the video subtitle translator works from a reviewed source.