Video captions: why they widen reach and how to do them well

Video captions usually get filed under accessibility. That’s true, and it undersells them. In a screen recording, the words often carry the meaning the pixels can’t. The narrator says “open the export menu and pick the second option” while the screen shows a dozen menus, and a viewer who can’t hear that sentence is left staring at a list of unexplained clicks. Take the audio away and a decent tutorial turns into a slideshow of cursor movements.

So treat captions as the channel that delivers your instructions to anyone who isn’t listening. That group is much bigger than most creators assume.

Who actually watches with the sound off

Three groups depend on captions in practice, and they overlap less than you’d think.

The first is people who can’t hear the audio well: deaf and hard-of-hearing viewers, and anyone watching somewhere sound isn’t an option. This is also the group the accessibility standards care about most. The Web Content Accessibility Guidelines (WCAG 2.2) require captions for prerecorded video with audio at Level A, the most basic conformance tier. If your tutorial lives in a help center or documentation site that has to meet those standards, captions are not optional.

The second group is the largest and the least discussed. These viewers can hear perfectly well and are watching on mute. They’re on a train, in an open-plan office, in a meeting where a colleague is on a call, or in bed. Feeds and embedded players often start videos muted, and a viewer who scrolls past a silent tutorial, stops, and decides to watch will usually stay muted unless the captions make the sound unnecessary.

The third group is people for whom the narration language is a second language. Reading a caption in a language you’re still learning is slower than hearing it, but it’s far easier than catching the rhythm of a fast speaker explaining a dashboard. Captions let them check a word they half-heard.

For the first group, captions are a baseline. For the second and third, they’re a reach strategy, because those viewers would otherwise leave.

Why screen recordings need captions more than most video

A talking-head video gives the viewer a face, a tone of voice and a second channel of meaning. A screen recording gives them dense, mostly static text, a moving cursor, and whatever the narrator says. The viewer’s eyes are already busy reading the interface, so the audio has to do the work of telling them where to look. Without it, they hunt.

There’s also a search effect, though it’s indirect and easy to overstate. A caption file is text with timestamps. A transcript published on the same page as the video gives readers and search engines words that describe what’s on screen: the button names, the feature names, the error message someone is trying to fix. A transcript alone won’t rank a video. But a page with the video and an honest, readable transcript has far more to offer than an embed sitting on its own.

Video captions are a readability problem first

Most teams treat captioning as a transcription job. Get the words down, export the file, done. The harder problem is making the words readable on a screen where the viewer is also trying to read a settings page. Three rules handle most of it.

Line length. The convention in broadcast and streaming subtitles is roughly 37 characters per line, with two lines at most on screen at once. Longer lines force the eye to travel back to the start of the next line, and every return costs a fraction of a second the viewer doesn’t have while a click is happening.

Duration. A caption has to stay up long enough to read, and no longer than the speech it matches. Many platforms publish a characters-per-second ceiling for captions. The exact figure varies by platform and audience, so check the guidance wherever you publish. The principle matters more than the number: a dense line that flashes for a second is unreadable, and a short line that sits for six seconds gets re-read while the viewer misses the next click.

Timing. A caption should appear as the words start, not after the cursor has already moved on. In a tutorial, the gap between a spoken instruction and the click it describes is where viewers lose the thread. If the narrator says “click Publish” and the caption arrives two seconds later, the viewer has already found the button and is wondering what the text is about.

Here’s a split I’d make. The narration is: Open the Integrations tab, then paste your webhook URL into the Endpoint field. A caption that breaks mid-phrase reads “Open the Integrations tab, then paste your webhook / URL into the Endpoint field.” It’s technically fine and harder to parse than it should be. A better split gives two captions in sequence. The first, “Open the Integrations tab,” shows while the cursor travels to the tab. The second, “paste your webhook URL into the Endpoint field,” shows while the cursor sits in the field. The text now follows the screen instead of racing it.

Auto-captions are a first draft, and they fail in predictable ways

Automatic speech recognition is good at ordinary conversation. It’s much weaker on the vocabulary that defines a software tutorial. Expect errors in four places.

• Product and feature names. A product called Tallyhouse, or a tab called Endpoints, comes back as two or three plausible English words. The recognizer has no way to know your brand is a proper noun.
• Acronyms. SSO, CSV, JSON and API are rendered inconsistently: “a pi,” “C S V,” “jason.” A viewer who reads “jason” in a developer tutorial will wonder whether the team knows what it’s building.
• Numbers and versions. “Version 2.1” becomes “version to one,” and dates, currency and percentages come out in mixed formats within a single video.
• UI labels spoken differently from how they appear. The narrator says “preferences” and the button says “Settings.” The caption copies the narration, so the viewer now has two words for one thing.

The fix is unglamorous. Keep a short glossary of the terms that matter: the product name, feature names, acronyms, and the exact label of each control you mention, spelled as it appears in the interface. Then proofread every caption against the frame where it’s spoken. For a three-minute video that’s about ten minutes of work, and it’s the most valuable ten minutes in the whole production, because the errors are where a careful viewer decides how much to trust you.

The captioning workflow, end to end

Here’s the order I’d follow.

1. Record with the narration you intend to keep. Captions are generated from the audio, so a rushed or mumbled narration produces a muddy caption file. A sentence you’d cut in the edit will still be captioned unless you cut it from the audio itself.
2. Generate the captions and export them. Most tools produce a standard caption file. SRT is a plain-text format with numbered cues and timestamps, and WebVTT is the web-native version of the same idea. Keep the file, because it’s the source you’ll correct and reuse.
3. Proofread against the screen. Open the video and the caption file side by side. Check every product name, acronym and button label against what’s visible at that second.
4. Check timing on the zoomed frame. Watch the first minute and confirm each caption appears as its action begins.
5. Publish the transcript where the video lives. A readable transcript on the same page serves readers who prefer text, and it gives search engines something to read.

Ten minutes per video is a realistic budget for steps three and four on a three-minute clip. It gets faster once the glossary is settled, because most errors repeat from one video to the next.

Where the captions sit, and what they cover

Captions default to the bottom of the frame. In a screen recording, the bottom is often where the important things live: a status bar, a toolbar, a submit button in a form that scrolls to its end, the taskbar on a desktop capture. A caption over the button the viewer is supposed to click is worse than no caption, because now they can’t see what the text is describing.

Two fixes work well. The first is to move captions to the top of the frame when the action sits at the bottom, which happens more often than people expect in web apps with fixed footers. The second is to size captions relative to the frame the viewer actually sees, not the full desktop. When you zoom in on a control, a caption sized for the whole screen can become enormous and swallow the area you zoomed to show.

Then check phone width. A caption that’s comfortable on a 27-inch monitor can become unreadable on a phone, where the whole frame has been scaled down to a narrow screen. Preview the video on a phone before you publish. If you can read the caption and see the control it refers to in the same glance, the placement works.

Why captions can compete with the screen

Here’s the tension most captioning guides skip. Research on multimedia learning, most associated with Richard Mayer, describes a redundancy effect: when on-screen text repeats exactly what a narrator says, learners can end up processing the same information twice, and that can slow them down rather than help. Captions are on-screen text that repeats the narration by design.

That doesn’t mean dropping captions. Accessibility and reach are good reasons on their own, and a viewer who can’t hear isn’t helped by a learning principle. It does change three things in practice. First, keep captions and narration aligned, so the viewer isn’t reading one thing while hearing another. Second, don’t narrate the whole screen word for word, because then captions and screen both repeat the narration. Third, if the screen holds something important, like an error message or a value the viewer must enter, let the narration point at it and keep the caption short, so the caption doesn’t bury the detail.

This is also why a good caption is often shorter than the sentence it replaces. The caption doesn’t need the filler the narrator used to buy time. It needs the instruction.

What captions do for reach, in practice

Consider a four-minute onboarding video for a project tool, shared in three places: a help article, a welcome email and a social post. The help article is read by people with the page open, so they glance at the video and then back at the text around it. The email is opened on a phone, often in a queue, with the sound off. The post autoplays muted as it scrolls past. In each case the video competes with something else for attention, and captions are what let it compete on equal terms.

Captions also help the people who watch at higher speed, the people who rewind to catch one word, and the people who want to skim a segment without listening to all of it. Each habit is common, and each is worse with uncaptioned audio.

The reach argument is less about a single audience and more about how many situations your video can be watched in at all. Captions expand that number without requiring a single new viewer to show up. For tutorial videos, that’s usually the most efficient gain available.

What captions can’t fix

Captions make a clear video clearer. They don’t rescue a video that wanders for three minutes before its first useful click. If the captions read well and viewers still drop off at 0:40, the problem is structure, not text. Start with a video that already knows what it’s trying to show, which is the subject of how to record a software tutorial people actually finish, and then caption it. Captions are the last layer, not the first.

RecordlyPro adds captions and chapters automatically, so the text is already timed to your clicks. What it can’t know is how your product is spelled, and that’s the part only you can check. Record one walkthrough in your browser with RecordlyPro, proofread the captions against the screen, and see how much those last ten minutes change the result. The gap between a caption that reads well and one that reads like a machine is mostly that step.

Keep reading

Playbook

Async video: stop scheduling the meeting you could record

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer October 6, 20262 min read

Playbook

Auto-zoom in screen recordings: what it is and why your demos need it

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer October 13, 20262 min read

Playbook

How to choose a screen recorder for product demos in 2026

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer October 16, 20262 min read

Explainer

Dofollow vs nofollow in 2026: what still passes value

The link attributes changed, Google's treatment changed, and a lot of advice is out of date. Here's what dofollow, nofollow, sponsored and ugc actually do now.

The Recordly Team October 10, 20262 min read