Subtitle Character Limits and Why Tools Miscount

Every subtitle tool will tell you a line is too long. Most of them are counting something other than what your reader sees, and for some languages the difference is close to double. That is worth understanding before you shorten a line that did not need shortening.

Where the limit comes from

The familiar number is 42 characters per line. It comes out of broadcast and streaming practice, where a two-line subtitle at around 42 characters a line fits comfortably on a television screen at a normal viewing distance without crowding the picture. Short-form vertical video generally wants less, because the frame is narrower and the phone is closer.

It is a sound convention, and the number is not where things go wrong. What goes wrong is what a computer does when you ask it how long a line is.

What a tool actually counts

Ask almost any program for the length of a piece of text and it returns the number of code units, which is the storage unit the text is kept in. For English that happens to equal the number of letters, so nobody notices the distinction. For a great many other scripts it does not.

Take Kannada. The word for Bengaluru is written ಬೆಂಗಳೂರು. A reader sees four units. A program counting code units returns eight. The syllable ಕ್ಕಿ is one unit to read and four to count. Across a whole line the error compounds: ನಮಸ್ಕಾರ ಬೆಂಗಳೂರು is ten units to a reader and sixteen to a naive count.

So a Kannada line that fits a 42 character limit comfortably gets reported as breaking it. Worse, an automatic line breaker acting on that number splits the line into two, and the caption gets worse because the ruler was wrong. The same applies to Devanagari, Bengali, Tamil, Telugu, Malayalam, Gujarati and Gurmukhi.

Grapheme clusters are the better measure

The unit that matches what a reader perceives is the grapheme cluster: a base character together with whatever vowel signs, marks and joined consonants hang off it. Count those and the Kannada line above measures ten, which is the number a Kannada reader would give you.

This costs nothing for English, because for Latin text the two counts are identical. It also fixes emoji, where a single visible emoji can be several code units, and accented letters written as a base plus a combining mark.

AutoCaption's subtitle validator and line breaker count grapheme clusters. If you have been fighting false warnings on Indic captions, that is the reason they stop.

What grapheme counting does not fix

Counting graphemes gets you the number of units a reader perceives. It does not tell you how wide they are, and width is what the limit is really about.

Urdu makes the point sharply. Measure Urdu text by code units or by grapheme clusters and you generally get the same number, so the fix above changes nothing there. Yet Urdu has a serious width problem of its own: in Nastaliq, the sloping style Urdu is traditionally written in, each word cascades downward and the width a word occupies depends on how its letters join. Two lines with an identical character count can be visibly different widths. No character count of any kind predicts that.

Telugu and Kannada raise the opposite problem. A syllable carrying a vowel sign and a subscript consonant is stacked vertically, so it is taller than a Latin letter rather than wider. A line can be within any character limit you like and still be too tall for the space you have given it. A character count cannot see height at all.

So what should you actually do

Treat the character limit as a proxy, and lean on the two checks that transfer better across languages.

The first is reading speed, measured in characters per second. It compares text against time rather than against width, so it survives the move to another script far better than a line-length limit does. There is more on how to use it in the guide to subtitle reading speed.

The second is looking at the captions. Put the video on a phone, in the app your audience uses, and see whether the lines fit and whether anything collides. That check costs a couple of minutes and it is the only one that accounts for the font, the frame and the platform's own overlays at the same time. It is also the only way to catch the Nastaliq and Telugu problems above, because no tool measuring text can catch them for you.

If you are starting from a video rather than an existing file, the caption generator produces an editable draft you can measure and re-break before export, which is easier than correcting a file after the fact.

And if a tool tells you an Indic line is too long when it plainly is not, now you know what it is counting.