Characters per second, and why it matters
Reading speed for subtitles is measured in CPS β characters per second, counted over the cue's on-screen duration. A 60-character line shown for two seconds is 30 CPS, which is too fast for comfortable reading in most languages.
The widely used ceiling is around 20 CPS for adult audiences, with children's content targeting closer to 13β15. Some broadcast specs allow bursts up to 25 CPS for short stretches, but sustained speed above 20 is the single most common complaint in caption quality reports.
The other three limits
- Minimum duration. A cue should stay up at least about 1 second (some specs say 5/6 second). Anything shorter flickers β viewers register movement but cannot read it.
- Maximum duration. Most guidance caps a cue at roughly 6β7 seconds, not because of reading speed but because a static line starts to look like a bug or a stray graphic.
- Line length. Around 32β42 characters per line, maximum two lines. Longer lines force the eye to travel further and make the cue feel faster than its CPS suggests.
What the major platforms ask for
| Context | Reading speed | Minimum | Notes |
|---|---|---|---|
| Netflix-style delivery | ~20 CPS | ~5/6 s | Two lines max, ~42 characters per line |
| Broadcast (UK-style) | ~17β20 CPS | ~1 s | Strict speaker-label and punctuation rules |
| Children's content | ~13β15 CPS | ~1 s | Slower by design |
| User-generated video | No enforced limit | β | Auto-captions frequently exceed 20 CPS |
Treat these as targets rather than laws. The specs that matter are the ones in your delivery contract; these figures are what to aim for when nobody has told you otherwise.
How to audit your own file
Reading the numbers cue by cue is tedious, so export the file and let a spreadsheet do the sorting. The subtitles to CSV tool writes one row per cue with its duration in milliseconds, which makes the audit mechanical:
- Convert the file to CSV.
- Add a column dividing the character count of the text by
duration_ms / 1000. - Sort descending β the top rows are your problem cues.
- Sort
duration_msascending to find cues that flash past.
In practice most files have a handful of offenders rather than a systemic problem, and fixing the worst ten cues noticeably improves how the whole track feels.
Fixing a cue that is too fast
You have two levers: shorten the text or lengthen the time. Which is correct depends on the material.
If the speaker was genuinely fast and the pause after the line is long, extend the cue's end time β but respect the next cue's start, because overlapping cues are worse than fast ones. If the line is simply verbose, edit it down. Professional subtitling is condensing, not transcribing; dropping filler and collapsing clauses is normal and expected.
Only resync the whole track when the problem is systematic. If most cues are fast, the file was probably timed against a different reading speed standard, and stretching every cue proportionally is quicker than editing each one.
Reading speed is not the same as comprehension
CPS is a proxy. A cue at 18 CPS with two dense clauses can be harder than one at 22 CPS with plain wording, and names, numbers and unfamiliar terms all cost more time than their character count suggests. Use the numbers to find candidates, then read the worst ones yourself.
If you are captioning for a language other than English, the 20 CPS figure is a starting point, not a constant β languages differ substantially in how much information a character carries, and several broadcast specs publish separate limits per language.