Right-to-Left Subtitles: What Breaks and What Does Not
Urdu and Arabic subtitle files hold no direction at all. What that means for line breaking, character limits, punctuation and fonts.
Urdu, Pashto, Sindhi, Arabic and Persian subtitles go wrong in ways that Hindi or Tamil subtitles do not, and the reasons are usually blamed on the wrong thing. It is worth separating what the file can actually get wrong from what only the player decides.
The file stores order, not direction
An SRT or WebVTT file holds characters in logical order, which is the order you would say them. Nothing in either format declares that a file is right-to-left. There is no direction field in SRT at all, and WebVTT does not have one either.
Direction is worked out by the renderer from the characters themselves, using the Unicode bidirectional algorithm. Arabic-script letters are strongly right-to-left, so a line of Urdu displays right-to-left without anything in the file saying so. That is why an Urdu subtitle file looks identical in structure to an English one.
One thing worth clearing up, because it causes real confusion: WebVTT's vertical cue setting is not for right-to-left text. It selects a vertical writing mode, the kind used for Japanese and Chinese, where lines stack sideways. Setting it on an Urdu file does not make the text right-to-left, it makes it vertical, which is not what anyone wants.
What breaking a line does, and does not, do
A common worry is that an automatic line breaker will scramble right-to-left text, or split an embedded English word or number. We tested ours against exactly that case, a line of Urdu with both a number and a Latin-script brand name inside it:
میں نے کل 25 ویڈیوز اپلوڈ کیں اور YouTube پر دیکھیں
broken at 42 characters becomes:
میں نے کل 25 ویڈیوز اپلوڈ
کیں اور YouTube پر دیکھیںThe break lands between words, both halves come out at twenty-five characters, the number and the brand name stay whole, the two lines rejoined are identical to the original, and no invisible direction-control characters are added. That is the behaviour to expect, and it is worth confirming in whatever tool you use rather than assuming.
A counting problem Urdu does not have
Most subtitle tools measure a line with a string length that counts UTF-16 code units. For Devanagari, Kannada or Tamil that is badly wrong, because a syllable made of a consonant plus a vowel sign is several code units and one thing a reader sees, so lines measure at roughly double their real width.
Arabic script is not affected in the same way. Each Urdu letter is normally a single code point, so a fifty-one character Urdu line counts as fifty-one either way. We measured that rather than assumed it. So if you have been told that character counting is broken for South Asian languages, that is true for the Indic scripts and not for Urdu, Pashto or Sindhi.
Which does not make the limit right. An Urdu line at forty-two characters is not the same physical width as an English one, because the letterforms and the joining behave differently. No character count of any kind measures rendered width. Watch it in the player.
Where right-to-left subtitles do go wrong
Punctuation at the boundary of a line is the classic one. A full stop or a question mark is direction-neutral, so where it lands is decided by the characters around it. A line ending in punctuation, or one that mixes an English clause into Urdu, can display with that punctuation at the end you did not expect. The text in the file is right; the resolution of it is not what you pictured.
This is not something to fix by editing bytes into the file. Check it in the player your audience actually uses, on a phone rather than a desktop preview, and reword the line if it reads wrong. Adding invisible direction marks to a subtitle file tends to create a second problem in the next player.
The other frequent fault is not direction at all but the font. If the player falls back to a font without proper Arabic-script support, letters stop joining and the line comes apart into disconnected shapes. That looks like a direction bug and is not one.
A short checklist
Read the proper nouns and any English terms first, since those are where recognition is least reliable. Settle one spelling for words you repeat, and the subtitle spelling checker will find a word your file writes more than one way. Then check line lengths with the validator and re-break with the line breaker, which does not disturb timing. Then watch the result on a phone, in the player, and judge the punctuation and the font there rather than in the file.
To build the caption track in the first place, start from the Urdu subtitle generator, the Pashto page or the Sindhi page, each of which covers what that language specifically gets wrong. If your audience reads Latin letters instead, the Roman Urdu caption generator sidesteps direction entirely. All of them run the same caption generator underneath, so the language choice is a starting point rather than a separate product.
Quick answers
Do subtitle files store text direction?
Neither format has a direction field. Both hold characters in the order you would say them, and the renderer decides which way to lay them out by looking at the characters themselves. Arabic-script letters carry that information intrinsically, which is why an Urdu file and an English file are structurally identical.
Does WebVTT's vertical setting make text right-to-left?
No. That setting is for writing that runs down the page, as Japanese and Chinese can, with lines stacking sideways. Applying it to Urdu rotates the text rather than mirroring it, which is a different thing entirely and never what anyone wanted.
Will an automatic line breaker scramble Urdu text?
A correct one will not, though it is worth proving rather than trusting. The test to run is a line carrying both a numeral and a Latin word, since those are the fragments most at risk. Confirm the two halves rejoin into exactly what you started with, and that nothing invisible has been inserted to hold the direction together.
Is character counting broken for Urdu the way it is for Hindi?
No, and the difference is worth knowing. The counting fault that inflates Devanagari and Kannada comes from syllables built out of several code points. Arabic script does not build words that way, so a count of Urdu is already the number you want. What a count still cannot tell you is width, which is a separate limitation shared by every language.
Why does my punctuation appear at the wrong end of the line?
A full stop belongs to no direction of its own, so it takes its cue from whatever surrounds it. Mix an English clause into an Urdu line and the resolution can land somewhere you did not picture, even though every character is stored correctly. Reword the line rather than reaching for invisible marks, which usually trade this problem for a worse one elsewhere.
My Urdu letters are not joining. Is that a direction problem?
That is the font, not the text. When a player cannot find a face that shapes Arabic script, the letters render as isolated forms instead of joining, and the word appears to fall apart. Nothing in your file is wrong, and no amount of editing will change it.