Subtitles, fixed cue by cue
Open an SRT or VTT, correct the wording and the timings, then tidy every line to a length and a duration a viewer can actually read. It all happens on your device — an odd thing to have to say about editing a text file, but most editors ask you to upload it.
Open the subtitles
A file, or a paste from somewhere else.
Drop an .srt or .vtt file, or click to choose
Your subtitles never leave your deviceFix the whole file at once
A shift for subtitles that are early or late; a tidy for lines that are too long or too quick.
Every cue, line by line
Times are checked as you type, so a malformed one is caught here rather than by the player.
Take it away
Back out as a subtitle file, or as plain text.
Editing subtitles without uploading them
Subtitle files are often the last thing standing between a finished video and publishing it — a mistimed line, a misheard name, a caption that flashes past too quickly to read. Most online SRT editors ask you to upload the file first, which is an odd thing to require for what is essentially a text document, especially when the subtitles belong to unreleased footage.
This editor reads the file in your browser. Each cue appears with its start time, end time and text, all editable. Timestamps are validated as you type, so a malformed time is flagged immediately rather than producing a file players silently reject.
The timing tools
Shift all moves every cue by the same number of seconds — the fix when subtitles are consistently early or late. Tidy timings enforces a minimum duration so no caption flashes past unreadably, adds a small gap between consecutive cues, removes overlaps, and re-wraps text to a maximum line length (42 characters is the usual broadcast convention). Split cuts a long cue in two at your cursor and divides its time proportionally; merge joins a cue to the one after it.
Reading speed is the real constraint
Line length and duration are two halves of one question: can this be read in the time it is on screen? The conventional ceiling is two lines of about 42 characters, and the timing has to match the amount of text. Around 17 characters per second is a widely used maximum for adult viewing, and materially lower for children's programming or anything that has to be read while something else is happening on screen.
The practical floor and ceiling matter too. A cue shorter than about a second cannot be read at all, however few words are in it — the eye needs time to find it before it needs time to read it. A cue much beyond seven seconds invites a viewer to read it twice and then wonder whether it is stuck. When a transcript is split into subtitles automatically, both ends of that range get violated regularly, and they are worth a pass of their own after any edit that moved timings.
When the text arrives as nonsense
If a subtitle file opens full of characters like é or ’ where accented letters and apostrophes should be, nothing is corrupted and the file is not broken. It is a text encoding mismatch: the file was written in one encoding and is being read as another, most often a legacy single-byte encoding being read as UTF-8 or the reverse.
This editor reads files as UTF-8, which is what effectively everything writes today. An older file from a Windows subtitling tool may not be, and the fix is to re-save it as UTF-8 in a text editor before opening it here rather than to repair the characters by hand — there are usually more of them than you think, and search-and-replace on mojibake tends to miss the ones that matter. Files this editor writes are always UTF-8, so a round trip through it settles the question permanently.