Subtitle Reverse Tool

The Subtitle Reverse Tool takes the SRT you paste into the SRT Content box and rewrites it with the cues in descending order of start time, so the last caption of the programme becomes cue number 1 and the first becomes the last. The cue text and the individual timecodes are carried over exactly as they were; only the sequence and the index numbers change. The result is a valid SRT you can download as a .srt file.

This is a deliberately specialised testing aid rather than a delivery tool. Localisation engineers working on Arabic, Hebrew, Farsi and Urdu subtitles need to know how their player, editor or web caption renderer behaves when cue order and reading direction do not match the naive assumption that files always run forwards. Reversing a known-good file is a fast way to generate that awkward input: you immediately see whether a tool sorts on load, whether it renders in file order, and whether a validator notices the backwards run. QA teams also use reversed files as a robustness test for ingest pipelines that quietly assume monotonically increasing timestamps.

Mechanically the tool parses the file into cues with numeric millisecond timings, sorts them so that the largest start time comes first, then serialises the list back to SRT with indices renumbered from 1 in the new order. No text transformation happens at any point - characters, line breaks, punctuation and any inline markup in the dialogue are untouched, and each cue keeps its own start and end pair, so durations are unchanged. Running the tool twice on the same file returns you to the original chronological order.

For actual right-to-left delivery you want a proper RTL formatter that handles directionality marks; this tool is for probing behaviour. It runs locally in the browser with no upload.

• Descending time sort: Cues are ordered from the latest start time to the earliest, producing exactly the backwards-running file that a sort-on-load bug will reveal itself against.
• Sequential renumbering: Indices are rewritten from 1 in the new order, so the output is structurally a valid SRT and not obviously broken by its numbering alone.
• Text left completely alone: No characters are added, removed, reordered or re-encoded, which keeps the reversed file a fair comparison against the original.
• Durations preserved per cue: Each cue keeps its own start and end timestamps, so only the ordering differs and any timing bug you find is genuinely about order.
• Perfectly reversible: Running the tool on its own output restores the original chronological sequence, which makes it safe to experiment with.
• One box, one action: The only control is the SRT Content textarea plus a run action, so there is nothing to misconfigure when you are generating a test case.
• Private by design: The reversal happens in your browser, so you can build test fixtures from real client files without transmitting them.

1. Start from a subtitle file you already know is correct, since the point of the exercise is comparing behaviour against a known-good baseline.
2. Paste that file into the SRT Content box, or click Load sample to generate a quick test fixture without supplying your own material.
3. Run the tool; there are no settings, because descending start time is the only ordering this test needs.
4. Confirm in the output that cue 1 now carries the latest timecode in the file and that the final cue carries the earliest.
5. Download the reversed file as a .srt and load it into the player, editor or ingest pipeline you are evaluating, noting whether it re-sorts, renders in file order, or raises a validation error.
6. Run the tool again on the reversed output to recover the original order, and use an RTL formatter rather than this tool when you move on to a real right-to-left delivery.

Example 1 - building a backwards test fixture. A three-cue extract is reversed so the closing line leads the file.

Before
1
00:00:01,000 --> 00:00:03,000
Good morning.

2
00:00:05,000 --> 00:00:07,000
Shall we begin?

3
00:00:09,000 --> 00:00:11,000
That is all for today.

After
1
00:00:09,000 --> 00:00:11,000
That is all for today.

2
00:00:05,000 --> 00:00:07,000
Shall we begin?

3
00:00:01,000 --> 00:00:03,000
Good morning.

Example 2 - checking a player's sort behaviour. Load the reversed file against picture: if the captions still appear at the correct moments, the player sorts by timecode on load; if they appear in file order, it trusts the sequence and your pipeline needs a sorting step before delivery.

• Finds order-dependent bugs early: You learn whether a player or ingest tool sorts by time or trusts file order before a real localisation delivery exposes the difference.
• Creates test fixtures in seconds: Hand-building a backwards subtitle file to probe a parser is tedious, and this produces one from any real file instantly.
• Gives a fair comparison: Because the text and durations are untouched, any difference you observe is attributable to ordering alone.
• Safe to try on real files: The operation is fully reversible, so an accidental run costs you one more click rather than a damaged asset.
• Supports RTL readiness work: Teams preparing Arabic or Hebrew subtitle workflows can validate tooling assumptions ahead of the first live job.
• Keeps client material confidential: Test fixtures derived from real programmes never leave your browser.