RTL Subtitle Formatter

The RTL Subtitle Formatter takes an SRT pasted into the SRT Content box and rewrites every cue so its text is wrapped in invisible Unicode bidirectional control marks. Cue numbers and timecodes are untouched; only the text lines change. The result is a standard SRT you can copy or save with the .srt extension.

Anyone producing Arabic or Hebrew captions meets the same frustration: the file looks correct in a text editor, then a player throws the punctuation to the wrong end of the line, or a phone number and a Latin brand name jump out of order inside an otherwise right-to-left sentence. That is the Unicode bidirectional algorithm resolving an ambiguous run from surrounding context that differs between renderers, and MENA localisation vendors delivering to unknown player stacks hit it constantly.

The fix is to make direction explicit instead of inferred. The formatter parses the SRT into cues and adds a directional control character before and after each cue's text. Those marks are zero-width: they take no space, are not drawn on screen and do not change what a viewer reads. Multi-line cues keep their line breaks, and numerals or Latin words sitting inside a right-to-left sentence are anchored by the surrounding marks rather than floating with whatever text ran before them.

Processing is entirely client-side with no upload, so unreleased episodes stay private and the output is byte-for-byte identical apart from the added marks.

• Explicit direction marks: Each cue's text is surrounded by Unicode bidirectional control characters so players stop guessing the paragraph direction from context. This is the difference between a line that renders correctly everywhere and one that only looks right in your editor.
• Timing is never touched: Only the text of each cue is modified. Start and end timecodes, cue numbers and blank-line separators come through the round trip exactly as they went in.
• Standard SRT in, standard SRT out: You paste into the SRT Content box and get a valid SRT back, so nothing downstream in your pipeline needs to change.
• Invisible in the rendered caption: The inserted marks are zero-width formatting characters, so viewers see the same words with the same spacing - only the resolved direction changes.
• Multi-line cues survive intact: Two-line and three-line cues keep their internal line breaks, so your reading-speed and line-length work is not undone.
• Handles mixed content: Cues that mix Arabic or Hebrew with Latin brand names, numerals, times or URLs are the exact case this is designed for, since those runs are what the bidirectional algorithm most often resolves badly.
• One-click operation: There is a single input and a Run button; there is nothing to configure, so it is safe to apply as a routine final step before delivery.
• Fully client-side: Nothing is uploaded, which keeps embargoed scripts and pre-release subtitles on your own machine.

1. Paste the Arabic or Hebrew subtitle file into the SRT Content box, or click Load sample to try the tool on a short example first.
2. Confirm the pasted text really is right-to-left content; running this on a purely Latin-script file adds marks that serve no purpose.
3. Press Run to rewrite the file, wrapping the text of every cue in directional control characters.
4. Read the result panel and check that the cue numbers and timecodes are unchanged and only the text lines were rebuilt.
5. Click Download to save the converted file with its .srt extension, or Copy if you are pasting it into another tool in your chain.
6. Load the saved file in the player or encoder you are actually delivering for and confirm that punctuation sits at the correct end of each line and that embedded numbers read in the right order.
7. Keep the original file as well, so you can compare the two if a platform ever rejects the marked version.

Example 1 - punctuation drifting to the wrong side. An Arabic cue ends with a question mark some players render on the left. Only the text is rebuilt, with an invisible mark at each end, shown here as bracketed labels because the real characters are zero-width.

Before:
7
00:01:12,480 --> 00:01:15,120
Where are we going?

After:
7
00:01:12,480 --> 00:01:15,120
[MARK]Where are we going?[MARK]

Example 2 - a number inside a right-to-left sentence. A cue quoting flight AF 447 is the classic case where digits and Latin letters swap places; wrapping the whole cue anchors the run so the mixed content keeps the order the translator intended.

• Consistent rendering across players: Making the direction explicit means the caption looks the same in VLC, on a set-top box and in a browser player, instead of depending on which bidirectional heuristic each one applies.
• Fewer rejected deliveries: Broadcast and platform QC frequently bounces Arabic and Hebrew files for reversed punctuation, and this removes the most common cause in a single pass.
• No re-timing risk: Because the tool only rewrites text, you can apply it at the very end of a finished, spotted subtitle without any chance of disturbing sync.
• Faster than fixing by hand: Inserting control characters manually in a text editor is slow and easy to get subtly wrong; here a full episode is processed in one click.
• Better viewer experience: Audiences reading Arabic or Hebrew captions get sentences that flow the way they were written, including embedded numbers, names and times.
• Private by design: Nothing is uploaded, so unreleased content and client-confidential scripts never leave your browser.