Urdu subtitle generator
Generate Urdu-script captions from video, review the wording and timing, and export an SRT file. Then know what happens to that file once a player gets hold of it.
Urdu is traditionally set in Nastaliq, the sloping style where each word cascades down toward the baseline. It is what Urdu looks like in print, and to a reader it is simply what the language looks like.
Digital media has largely gone the other way. Naskh, the flatter Arabic-style script, sits on a consistent line and is far cheaper to render, so it has become the common default. Nastaliq needs many times more glyphs and genuine two-dimensional positioning, and its fonts run to megabytes, which is why editors and players reach for Naskh instead.
The consequence for subtitles is blunt: a subtitle file carries text, not fonts. Ship an SRT and the player decides the typeface, which usually means Naskh. The captions are readable and correct, but they will not look the way Urdu is supposed to look, and some of your audience will notice.
Burning the captions into the video is the only way to guarantee the typeface, because then the font is baked into the pixels rather than chosen at playback. Noto Nastaliq Urdu is the usual choice.
The trap is vertical space. A cascading baseline means a Nastaliq line reaches well below where a Naskh line would stop, so at normal line height the descender of one line runs into the line beneath it. Nastaliq generally wants somewhere around 2.0 to 2.4 line-height to stay clear, roughly double what you would give Naskh. Two-line Urdu captions therefore occupy far more of the frame than the same two lines in English, which is worth knowing before you place them over a face.
This is also the argument for exporting both: burn in captions for the platform that autoplays muted, and keep the subtitle file for everywhere else.
Urdu runs right to left. Digits and English words run left to right. A caption containing both has to be resolved into one display order, and the subtitle file does not say how: SRT carries no direction markers at all.
So the player resolves it, using the Unicode bidirectional algorithm, and players do not always land in the same place. That is the mechanism behind the common complaint that a year, a price or a brand name sits in the wrong position, and behind the more confusing version where the same file looks correct in one app and wrong in another.
There is no setting in the file to fix this. What works is checking a caption that contains numbers in the player your audience actually uses, and where the order comes out wrong, rewording so the number is not stranded mid-sentence.
Urdu digits are not the same characters as the 0 to 9 on your keyboard. They are a separate range entirely, which means a caption file can contain both without anything flagging it, and they will render as visibly different numerals in the same video.
It is the same class of fault as inconsistent spelling, and the same fix: decide which set the file uses, then make it agree. Note that the spelling consistency checker will not catch this one, because it examines words in Latin letters. Its find and replace will still do the correcting once you have spotted it.
Worth stating plainly, because the honest answer is less flattering than the marketing one. AutoCaption measures caption lines in grapheme clusters rather than code units. That genuinely fixes line measurement for Devanagari, Kannada and the other Indic scripts, where a syllable is several code units and one visual unit.
For Urdu it changes essentially nothing, because the two counts come out the same. And Urdu has a width problem anyway, just a different one: in Nastaliq the width a word occupies depends on how its letters cascade into each other, so two lines with an identical character count can be noticeably different widths. No character count of any kind predicts that.
So treat the limit in the validator as a rough guide for Urdu rather than a measurement, and look at the captions in the player. Reading speed, which the validator also reports, transfers better, because it counts characters against time rather than against width.
This is an audience question rather than a correctness question. Urdu script is what a reader of published Urdu expects, and it is the right default for anything formal or long-form. Roman Urdu reaches people who speak Urdu fluently but read the script slowly, which is a large part of a young social-video audience, and it sidesteps every rendering problem on this page because Latin letters render the same everywhere.
It brings its own fault in exchange. Roman Urdu has no standard spelling, so a draft writes the same word several ways in one file. The Roman Urdu caption generator covers that workflow, and the spelling consistency checker finds the variants. Plenty of creators publish Roman Urdu for short-form and Urdu script for long-form, which is a reasonable answer rather than a compromise.
For neighbouring languages, the Punjabi caption generator covers Shahmukhi and Gurmukhi, the Sindhi and Pashto pages cover the other Perso-Arabic scripts, and the South Asian language hub lists them all.
If you ship a subtitle file, that is not your decision. A subtitle file carries text, not fonts, so the player picks. Most players and editors default to a Naskh-style face, because Nastaliq is far more expensive to render, so Urdu that you wrote expecting Nastaliq will often appear in Naskh. It stays readable, but to many Urdu readers it looks like Arabic rather than Urdu.
By burning the captions into the video, which is the only way to control the typeface. Noto Nastaliq Urdu is the usual choice. Budget for it in the layout, because Nastaliq needs roughly 2.0 to 2.4 line-height to stop the cascading baseline of one line colliding with the next, where Naskh is fine at normal line height.
Because the file does not say which way they should run. SRT has no direction marker, so a line mixing right-to-left Urdu with left-to-right digits or English is resolved by the player using the Unicode bidirectional algorithm. Different players can reach different display orders from the same file, which is why a caption can look right in one and wrong in another. Check it in the player your audience actually uses.
No, they are different characters. Urdu digits are a separate set of code points from the 0-9 on your keyboard, so a file can silently contain both and they will render differently. Pick one and hold it across the file, the same way you would with spelling.
Less well than for other scripts, and it is worth being straight about why. AutoCaption counts grapheme clusters rather than code units, which fixes line measurement for Devanagari and the other Indic scripts. For Urdu the two counts are usually identical, so that fix changes nothing here. Urdu's problem is different: in Nastaliq the width of a word depends on how its letters cascade, so no character count of any kind predicts the rendered line well. Treat the limit as a rough guide and look at the player.
Ask who is reading, not which is more proper. Formal or published work belongs in Urdu script. A young social audience often speaks Urdu fluently and reads the script slowly, and Latin letters remove that friction entirely. If you are unsure, the deciding question is whether your viewers read Urdu newspapers or mostly read phone screens.
SRT and WebVTT subtitle files, a plain transcript, or a video with captions burned in. Export the subtitle file even if you also burn captions in, because a file can be corrected, converted and re-uploaded later.
Generate Urdu captions, review the wording, then export a subtitle file you keep.