Remove HTML Tags from Subtitles
Or paste subtitle text
Options
One box, seven choices, and each choice has a page of its own. Italic, bold, underline and colour remove that one kind of range and leave the rest of the line's styling alone. All removes every range the tool models — those four plus karaoke timing — while leaving everything else in the text untouched. HTML does the same and then also sweeps out the angle-bracket markup that was left in the text because the tool does not model it, such as VTT's <v Bob> speaker tags and <c.className>. ASS does the same for override blocks instead, clearing the {...} codes that were not recognised at parse time, such as {\fad(500,500)}. 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 takes the markup out of subtitle text: every styling range a file carries, plus the angle-bracket tags that are left over in the text itself. What comes back is plain readable dialogue — the words, the timings and nothing else. It is the run for a file whose text still has things like a speaker tag, a class tag or a stray closing tag sitting in the middle of a line.
That second half is why this page exists next to Strip All Formatting from Subtitles. The tool models the four emphasis tags it understands and leaves everything else exactly where it found it, which is the right call while reading a file — silently eating markup it does not recognise would be losing data. But it means a WebVTT file with `<v Bob>` in it keeps that tag through every other cleanup on the site, and a file that has been through OCR or hand-editing often has an unmatched closing tag in the middle of a line. This page is the one that sweeps them out, and its title says so.
The sweep is deliberately narrow. It only removes something shaped like a tag — a letter or a slash immediately after the opening bracket. A comparison in the dialogue such as `5 < 10` and a sad face such as `<3` are left completely alone, because a looser rule would delete the words between the two brackets and leave nothing in the output to show that it had. What is not modelled is not guessed at.
Nothing is uploaded; the file is read and written inside the browser tab. A file that is already plain text comes back byte for byte, which is also the cheapest way to find out whether the invisible markup you suspect is really there.
Examples
A WebVTT file with a speaker tag and a class tag
Input
WEBVTT
00:00:01.000 --> 00:00:02.000
<v Bob><c.yellow>Hello there</c>
00:00:03.000 --> 00:00:04.000
<i>She left</i> <ruby>東京<rt>とうきょう</rt></ruby>.
Output
WEBVTT
00:00:01.000 --> 00:00:02.000
Hello there
00:00:03.000 --> 00:00:04.000
She left 東京とうきょう.
Speaker tag, class tag, italic and ruby annotation all go, leaving the words. Note the second cue: the reading inside `<rt>` was text rather than markup, so it stays — the output shows the kana beside the kanji, which is what a player would have displayed anyway.
An SRT file with an unmatched closing tag
Input
1
00:00:01,000 --> 00:00:02,000
<i>Hello</i> there</i> again.
2
00:00:03,000 --> 00:00:04,000
<b>And</b> one more.
Output
1
00:00:01,000 --> 00:00:02,000
Hello there again.
2
00:00:03,000 --> 00:00:04,000
And one more.
The pair around `Hello` was read as a range and removed as one; the stray `</i>` after `there` was left in the text by the reader and is swept here. Both end up out of the output, which is the point of doing the two jobs in one run — mismatched tags like this are what a file comes back with after OCR or hand-editing.
Comparisons and symbols are not tags
Input
1
00:00:01,000 --> 00:00:02,000
5 < 10 and 3 > 1
2
00:00:03,000 --> 00:00:04,000
<3 you
Output
1
00:00:01,000 --> 00:00:02,000
5 < 10 and 3 > 1
2
00:00:03,000 --> 00:00:04,000
<3 you
Nothing is removed, and this is the half of the page that matters most. The sweep only touches something shaped like a tag, meaning a letter or a slash right after the bracket; a mathematical comparison and a heart made out of a less-than sign both survive untouched, and so does everything written between two brackets.
Frequently asked questions
What is the difference between this page and stripping all formatting?
This one does that job and then goes further. Removing formatting takes out the emphasis ranges the tool models — italic, bold, underline, colour and karaoke. This page removes those too, and then sweeps the angle-bracket tags that are left in the text itself: speaker tags, class tags, ruby markup and stray or unmatched closing tags. If your file has no markup like that in it, the two pages produce the same output.
Which tags does the sweep remove, and which does it leave?
It removes anything shaped like a tag: an opening bracket followed immediately by a letter or a slash, up to the next closing bracket. What it does not touch is a bracket followed by anything else, so a comparison like `5 < 10 and 3 > 1` and a symbol like `<3` pass through untouched. That narrowness is deliberate — a wider rule would delete dialogue between two brackets and leave no trace in the output.
Does this page remove the words that were inside a removed tag?
It depends what was inside. A tag's own attributes go with it, and so does anything nested inside a tag that is itself being removed — the reading inside a ruby annotation, for example, is text and stays in the line while the ruby markup around it disappears. What never happens is removing text that sits between two brackets in ordinary dialogue, because that is not shaped like a tag.
Will the output still be valid in my player after the markup is gone?
Yes, and more reliably than before. WebVTT allows an unmatched closing tag without complaint, but a speaker tag whose closing bracket is missing can swallow the rest of the line in some players, and different players disagree about what an unfamiliar tag means. Plain text has no such ambiguity, which is why a file for a platform that overrides styling is often better off cleaned than styled.
Can I remove only the leftover markup and keep my italics?
Not on this page: the emphasis ranges go first and the sweep runs after, so a file with italics comes back without them. That order is not arbitrary — removing markup shortens the text, and every range after the removal would have to be recalculated to keep pointing at the right characters. Doing the two jobs together is what makes the result exact, so there is no half-way setting here.
Why did the run report nothing when my file clearly had markup in it?
The likely reason is that the markup is not shaped like a tag: a bracket followed by a space, a digit or a symbol is left alone on purpose, so nothing was removed and the file came back byte for byte. If the file does contain something like `<v Bob>` and still comes back unchanged, check that it is the file you think it is — the page reads a file for the format it actually is, not for the extension it carries.