An adult reads prose at around 250 words a minute, which is roughly 20 characters per second. Subtitle specifications cap you at 17, and often lower. The gap between those two numbers is the whole subject.
A subtitle is not read the way a page is. The viewer is looking at the picture, and reading is something they do in the time left over — dropping to the bottom of the frame, taking in the line, and getting back up in time to see what happens. A cue that can be read at exactly the pace of the speech is one the viewer reads instead of watching the film, which is a subtitle that has failed at its job while passing every test you could set it.
Characters per second, and why not words
The measure everyone uses is characters per second: the number of visible characters in a cue divided by how long it is on screen.
Not words, because words are not a constant. "Yes, I did." and "Absolutely unprecedented circumstances." are three words each and are not the same amount of reading. Characters track the actual quantity of text closely enough, and they are trivial to count, which is why every house style in the industry is written in them.
The figures in circulation: 15 to 17 for adult programming is where most broadcast specifications sit. Netflix caps most languages at 17, drops to 13 for children’s content, and allows 20 in its English timed-text guide. Anything past 20 is being skimmed. Past 25 the viewer is reading the first half of the line and inferring the rest.
These are house styles rather than laws, and they differ because the audiences differ. The right number is the one in the specification you are delivering against — which is why the reading speed checker makes the threshold a setting rather than baking one in.
The cue that fails never looks like the problem
This is the part worth taking away, and it is why reading through a file does not find these.
Take two cues from the sample on that page. Cue 2 is "There is room here to say rather more than you would think." — 59 characters over three and a half seconds, which is 16.9 per second. It passes.
Cue 3 is "He said the whole thing again, faster, and nobody caught it." — 60 characters over 1.4 seconds. That is 42.9 characters per second, two and a half times the limit, and it is unreadable.
One character apart. Read those two cues in a text editor and nothing distinguishes them: both are one ordinary line of dialogue of ordinary length. The length is not the fault. The fault is the pairing of that length with that duration, and duration is the column nobody scans.
That is the entire argument for measuring rather than reading. A file can be proofread by three people, all of whom read every line, and every one of them will read cue 3 at their own pace with no video playing and think it fine.
Line length is a different limit
Reading speed is about time. Line length is about space, and a cue can pass either while failing the other.
Characters per line — CPL — is capped at around 42 for Latin scripts. Past that the text runs to the edges of the frame or the player wraps it for you, and a player’s wrap is purely mechanical: it breaks at whichever word runs out of room, not where the sense breaks. A line reading "he told her he had never once considered leaving" wrapped after never gives the viewer a clause that means the opposite for the third of a second before the second line lands.
The figures differ for the same reason the speeds do. 42 is Netflix for most Latin languages. 37 is teletext, still the working figure across much of European broadcast, because a teletext row was 40 characters wide and needed margins. 39 is a common house compromise. Cinema runs wider than any of them.
Lines per cue is capped at two. A third line is permitted by most specifications and recommended by almost none: the block climbs high enough to cover the picture, and three lines take longer to read than many shots stay on screen, so the viewer loses either the line or the shot.
And this is the case a speed check cannot catch. A cue of three short lines — Longer / than you / would think. — is 28 characters. It is fast enough to read by any measure and it is still wrong. The line length checker exists for that specific gap.
Count what is on screen, not what is in the file
<i>whispering</i> is ten characters on screen and twenty-seven in the file. Counting the file over-reports — flagging cues that are perfectly fine — and, less obviously, under-reports: a heavily tagged cue can sit under the limit as written and be over it once the tags come off nothing.
The same applies to the line break inside a two-line cue. For reading speed it should be counted as a space, because the viewer reads the two lines as one sentence; counting the newline as a character inflates every two-line cue by one. For line length it must not be flattened at all, because where the break falls is the entire question. The two checks want the same text in two different shapes, which is why they are two checks.
What to do with a cue that fails
Three options, in the order a subtitler tries them.
Cut words. Subtitling is not transcription. Repetitions, names the viewer can see being addressed, and the second half of a redundant phrase all come out, and the meaning survives. This is the fix most of the time.
Give it more time. A cue can start slightly before the line is spoken and run slightly past it, within limits — but the end has more room than the start, because a start that drifts is a subtitle out of sync with a mouth. Extending short cues mechanically only works where there is silence after them to extend into.
Split it in two. Only if there is a pause in the delivery to split at. Two cues where the speech is continuous produces a flicker, which is worse than the problem you started with.
What no tool should do is any of these for you. Where to cut a word and where to break a line are decisions about meaning, and a machine that makes them produces the same mechanical wrap the player would have produced anyway. Measuring is the part that can be automated; the fix is the translator’s.