A subtitle can be perfectly accurate and still fail. If a line leaves the
screen before the viewer has finished reading it, the viewer has missed it.
Reading speed, measured in characters per second (CPS), is how
subtitlers catch that before anyone watches the video.
This post covers the limits the big style guides use and how to convert
between CPS and words per minute. It then runs a small experiment on
machine-made subtitles. The finding surprised us: most "too fast" subtitles
from AI transcription aren't too wordy. They're timed too tightly, and you
can fix most of them without deleting a single word.
What CPS measures
CPS is the number of characters in a subtitle divided by how long it stays on
screen:
CPS = characters in the cue ÷ seconds on screen
A 42-character line shown for 2 seconds runs at 21 CPS. The same line shown for
2.5 seconds runs at 16.8 CPS.
Two details change the result, so check them before you compare numbers
between tools:
- What counts as a character. We count every character the eye reads, including spaces and punctuation, and leave out only the line break between two rows. Some tools skip spaces or punctuation. Their numbers come out lower for the same subtitle.
- Which duration counts. The time on screen is the cue's end time minus its start time. It is not how long the person took to say the words. That difference is the whole story of the experiment below.
The limits in the major style guides
| Guideline | Reading speed | Line length | Lines | Duration |
|---|---|---|---|---|
| Netflix, English (adult) | up to 20 CPS | 42 characters | 2 max | 5/6 s to 7 s |
| Netflix, English (children's) | up to 17 CPS | 42 characters | 2 max | 5/6 s to 7 s |
| Netflix, Simplified Chinese (adult) | up to 9 CPS | 16 characters | 2 max | 5/6 s to 7 s |
| Netflix, Japanese | up to 4 CPS | 13 full-width characters | 2 max | 5/6 s to 7 s |
| BBC | 160–180 words per minute | about 68% of a 16:9 frame width | 2 (3 if nothing important is covered) | about 0.3 s per word minimum |
A few things stand out:
- Chinese and Japanese limits are far lower, because each character carries much more meaning than a Latin letter. A Latin-script limit would never flag anything in Chinese text. You need a separate threshold for each script.
- The maximum is not a target. Netflix drops to 17 CPS for children's programs, and the BBC's 160–180 words per minute works out to about 14–16 CPS (see below). Aiming below the ceiling leaves room for viewers who read slowly or are reading in a second language.
- Minimum duration matters as much as the speed limit. Netflix's 5/6 of a second (20 frames at 24 fps) exists because a flash of text is hard to catch even when it is short.
Converting words per minute to CPS
Speech and subtitle guidelines often use words per minute (WPM). To convert
between the two, you need the average characters per word, including the space
after each word.
In the English sample we measured below (447 words, 2,413 characters), that
came to 5.4 characters per word. So, for English:
| Words per minute | ≈ CPS |
|---|---|
| 140 | 12.6 |
| 160 | 14.4 |
| 180 | 16.2 |
| 200 | 18.0 |
| 220 | 19.8 |
So the BBC's 160–180 WPM works out to about 14–16 CPS in our counting,
noticeably below Netflix's 20 CPS adult ceiling. Audiobooks are commonly
recommended at 150–160 WPM; the explainer voice in our test below ran at 189. A
word-for-word subtitle of a fast talker can therefore break a 17 CPS limit on
text alone. But as the experiment shows, text is usually not the main cause.
An experiment: where AI subtitles break the limit
The audio. We used the English voiceover from our own product video: 2
minutes 48 seconds, 447 words, one clear synthetic voice with natural pauses
between sentences. The words take up 142 seconds of that time, and within those
seconds the voice runs at 189 WPM (17.0 CPS). That's a brisk but normal
explainer-video pace.
The subtitles. We transcribed it with Whisper (the open-source base
model, run locally). We then cut the result into subtitle cues with the same
splitting rules ScribeToAny's engine uses for exported SRT files:
- at most 84 characters per cue (two lines of 42);
- at most 7 seconds per cue;
- break at the end of a sentence first, then at a clause.
Each cue starts at its first word and ends at its last word.
The check. We counted every cue against 17 and 20 CPS, the two Netflix
English limits, and flagged cues shorter than 5/6 of a second. We then applied
two standard fixes, one at a time.
| Step | Cues | Median CPS | Over 17 CPS | Over 20 CPS | Shorter than 5/6 s |
|---|---|---|---|---|---|
| A. Cues timed to the words | 69 | 19.3 | 47 (68%) | 29 (42%) | 17 |
| B. + end extended into the following pause | 69 | 15.5 | 20 (29%) | 9 (13%) | 9 |
| C. + short neighbours merged | 41 | 15.5 | 10 (24%) | 3 (7%) | 1 |
What the numbers say
Timed to the words, two thirds of the cues were "too fast." Yet the audio
averages exactly 17.0 CPS while someone is talking. The average cue was not
too wordy. Cues that start and end exactly with the speech leave no reading
time, and the short ones suffer most. For example:
- "Need more?" was on screen for 0.36 s, which works out to 27.8 CPS.
- "Fix it right there." lasted 0.6 s, which works out to 31.7 CPS.
Using the pauses fixed more than half of the failures. For step B, each
cue's end time moves forward into the silence before the next line starts. We
left an 80 ms gap (about 2 frames at 25 fps) and capped each cue at 7 seconds.
That alone took the cues over 17 CPS from 47 to 20, without changing a word.
Merging short neighbours fixed most of the rest. For step C, a cue that
was still too fast merged with the next one when the result stayed within 84
characters and 7 seconds. We only merged where the combined text ended at
punctuation, so no subtitle ends mid-phrase.
- A 0.44-second "Turn on" fragment rejoined the rest of its sentence, "detect speakers, and every line gets a speaker label." The merged cue runs at 15.7 CPS.
- Cues over 20 CPS fell to 3 of 41.
What's left is a small editing job. To bring every remaining cue to 17 CPS,
you would need to cut 40 characters out of 2,399, about 1.7% of the text.
To reach 20 CPS, you would cut 5 characters. That is where a human makes
choices: dropping a filler word, or shortening "Then take it out in the format
you need" to "Then export it."
The caveats. This is one recording, with one voice, and with clean pauses
between sentences. A real conversation has fewer pauses, overlapping speakers
and faster bursts, so steps B and C buy less there and condensing matters
more. But the ordering holds in general: fix the timing before you cut
words.
Fixing a fast subtitle, in order
- Extend the end time into silence. If the next line doesn't start immediately, let the current cue stay on screen longer. Keep a small gap of about 2 frames before the next cue, so the viewer can see that the subtitle changed.
- Respect the minimum duration. Nothing should flash on screen for less than about 5/6 of a second, even a one-word "Yes."
- Merge short neighbours. Two quick lines from the same speaker often read better as one two-line subtitle. Stay within your line and duration limits, and don't merge across a change of speaker.
- Only then, condense. Remove fillers ("you know," "basically"), false starts and repeated words. Keep the meaning, names and numbers. For a verbatim or legal transcript you wouldn't do this, but subtitles are a reading aid, not a record.
- Break lines in sensible places. When a subtitle needs two lines, break after punctuation, or before a conjunction or preposition. Netflix's style guide asks you not to split an article from its noun or a first name from a last name. It also prefers a bottom-heavy shape, with the longer line underneath.
Chinese, Japanese and Korean
For these scripts, character counts behave differently:
- Netflix's Simplified Chinese guide allows 9 CPS and 16 characters a line.
- Its Japanese guide allows 4 CPS and 13 full-width characters.
A Latin 17 CPS threshold would pass almost any Chinese subtitle, however
cramped. Choose the threshold by the script on screen, not by the source
language. An English translation of a Chinese video is checked as English.
Checking reading speed in ScribeToAny
ScribeToAny's transcript editor has a QC mode on every plan, free
included. Turn on Reading-speed & line checks and each cue shows the
following:
- its CPS, amber when it gets close to your limit and red when it goes over;
- the character count of each line, with lines over the limit flagged;
- whether a cue is under 5/6 of a second or over 7 seconds, or too close to the previous cue.
The defaults are the conservative ones:
- 17 CPS and 42 characters a line for Latin scripts;
- 9 CPS and 16 characters for Chinese, Japanese and Korean, picked automatically from the text on screen.
You can change both numbers, for example to 20 CPS for Netflix-style adult
English. You can edit start and end times directly, split a cue or merge it
with the next one, and roll back to an earlier version. Then export SRT or VTT
with the same timings.
To be clear about what it doesn't do: QC mode flags problems. It doesn't
retime cues for you. Steps 1 to 4 above are still your call. That's
deliberate. A tool that silently stretches or rewrites subtitles makes
decisions only a person watching the video can make.
If you only need to adjust an existing SRT file, the free
SRT editor runs in your browser without an account. It
doesn't show reading-speed checks.
Related:
Sources
- Netflix, English (USA) Timed Text Style Guide: 42 characters a line, up to 20 CPS for adult programs and 17 for children's, and line-break rules.
- Netflix, Timed Text Style Guide: General Requirements: 5/6-second minimum, 7-second maximum, 2 lines.
- Netflix, Chinese (Simplified) Timed Text Style Guide and Japanese Timed Text Style Guide.
- Wikipedia, Words per minute: 150–160 WPM recommended for audiobooks.
- BBC, Subtitle Guidelines: 160–180 words per minute, line width and line count.
- Experiment: our own measurement on September 24, 2026, as described above.
The cue-splitting rules are the ones our transcription engine uses. Our
production service runs larger Whisper models than the
basemodel used here, which mainly affects word accuracy rather than timing.
Originally published on the ScribeToAny blog.
Top comments (0)