Remove Bracketed Text from Subtitles
Or paste subtitle text
Options
One box, five choices, and each choice has a page of its own. Brackets removes paired [square] asides, parentheses removes paired (round) ones, speaker removes an all-capitals name and the colon after it at the start of a line, and music removes the note symbols. All four at once is the choice called All. Every one of them edits the words themselves rather than the styling, so the line gets shorter — and unlike the styling pages, an annotation that was removed cannot be put back by the tool that reads the result. This page fills the box in with the choice its title names and lists no other.
Which frame rate the timings are counted in. On the format pages this is what MicroDVD needs, because it stores timing as frame numbers. On the frame rate pages it is the rate the file was timed against — the version the subtitles were made for — and the page's second box takes the rate of the video you are going to use them with. 23.976, 24, 25, 29.97, 30, 50, 59.94 and 60 are the common ones. Getting it wrong shifts the whole timeline, and on the frame rate pages it shifts it by a ratio rather than by a fixed amount.
This page deletes everything inside a paired set of square brackets and closes up the space where it was. That is the whole job. `[door slams] I heard that.` comes out as `I heard that.`, and the cue keeps its start, its end and its number.
Square brackets in a subtitle file carry two things. One is sound and music: `[door slams]`, `[phone rings]`, `[music]`, `[inaudible]`. The other is who is speaking: `[BOB] I heard that.` This page does not tell them apart, because to a reader they are the same shape and the thing you want gone is the same shape too.
The pairing is counted, not assumed. A bracket inside a bracket is one annotation and the whole aside goes together, so `He points [at the door [twice]] and leaves` comes out as `He points and leaves` with nothing left over. A bracket that is never closed is left completely alone: `Hello [door slams` does not say where the annotation ends, and a tool that guessed would be choosing which of your words to delete with nothing in the output to show it had. A stray closing bracket with no opening one is left alone for the same reason.
Round brackets are not touched here. They belong to the non-speech page, and keeping the two apart is deliberate: files in the wild use one shape or the other by house style, and a page that took both would remove twice as much of your dialogue as its title promises. If your file mixes the two, the SDH page takes both in a single run. Nothing is uploaded, and every format the site reads is accepted, since the annotation is in the words rather than in the file's markup.
Examples
A WebVTT file with a cue at each end of the line
Input
WEBVTT
00:00:01.000 --> 00:00:03.000
[door slams] I heard that.
00:00:04.000 --> 00:00:06.000
She left. [footsteps fade]
Output
WEBVTT
00:00:01.000 --> 00:00:03.000
I heard that.
00:00:04.000 --> 00:00:06.000
She left.
One annotation opens the first line and one closes the second, so the spacing has to be tidied in both directions. Without that step the second line would read `She left. ` with a trailing space, and a bracket at the end of a line is exactly where that shows up. The WEBVTT header and the cue timings are the file's own and come back unchanged.
A bracket inside a bracket
Input
1
00:00:01,000 --> 00:00:03,000
He points [at the door [twice]] and leaves
Output
1
00:00:01,000 --> 00:00:03,000
He points and leaves
The inner pair is part of the outer remark, so the whole thing goes as one piece and the sentence closes up behind it. Treating the first closing bracket as the end would have left a stray `]` sitting in the middle of the line — text the tool had no business touching, and hard to spot in a file of a thousand cues.
A bracket that was never closed
Input
1
00:00:01,000 --> 00:00:03,000
Hello [door slams
2
00:00:04,000 --> 00:00:06,000
a stray ] bracket
Output
1
00:00:01,000 --> 00:00:03,000
Hello [door slams
2
00:00:04,000 --> 00:00:06,000
a stray ] bracket
Both cues come back byte for byte. The first has an opening bracket with no closing one, the second a closing bracket with no opening one, and neither says where an annotation starts and stops. Removing to the end of the line in the first case would have taken words that were never inside a bracket at all.
Frequently asked questions
What does this page treat as a bracketed annotation?
Anything between a square bracket and its matching closing bracket, on the same line. The bracket pair is matched by counting, so a bracket nested inside another is part of the same annotation rather than the end of it. Both the brackets and the text between them are deleted, and the space the deletion leaves behind is closed up so the line reads as a sentence.
Are the round brackets in my file removed too?
No. This page only pairs `[` with `]`. Round brackets are handled by the non-speech information page, which is the same operation pointed at the other bracket shape. Two pages rather than one because files use one shape or the other by house style, and a single page taking both would remove remarks you meant to keep. If you want both kinds gone at once, the SDH annotations page does that in one run.
Why is there still a bracket in the output?
Because it was not part of a pair. `[door slams` with no closing bracket, or a `]` with no opening one, gives the page no way to tell where the annotation begins and ends, so it leaves the line untouched rather than guessing. Check the line in the file: an unbalanced bracket usually means the annotation was cut short when the file was edited, and it is worth fixing at the source.
Does removing bracketed text change the timecodes or the cue numbers?
No. The page edits the text of each cue and nothing else, so every start and end stays exactly as the file wrote it and the cue numbers are the file's own. The only case where a cue disappears is when every line of it was a bracketed remark, because then there is no dialogue left to display — and that is counted in the report.
Will it take out a speaker name in square brackets?
Yes, and for most people that is the point. `[BOB] I heard that.` is a speaker label written in square brackets, which is the same shape as a sound cue, so both are removed. A file that marks speakers that way and a file that marks sounds that way need the same edit, and the page cannot tell which is which without reading the film.
Which formats does the bracket removal work on?
All twelve the site reads: SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON, plain text and CSV. The brackets are in the cue text, and every one of those formats carries cue text, so nothing is excluded. The file is read for what it is rather than for its extension, and WebVTT files keep their header and block layout untouched.