Remove ASS Override 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 clears the override codes out of an ASS or SSA file: the styling ranges, the karaoke timing, the leftover effect blocks and the positioning. What comes back is plain timed text — the words, the cue timings and the file's own structure, with the lines sitting wherever their named style puts them.
ASS is the format that can say the most, and most of what it can say is written as override codes inside the text of a line. Some of those codes are styling the tool models — `{\i1}`, `{\b1}`, `{\c&H...&}`, `{\k50}` — and some are effects it does not: fades, moves, scaling, blurring, all written as blocks in the same shape. Those unmodelled blocks are left in the text while a file is being read, deliberately, because eating markup the tool cannot read would be losing data. This is the page that sweeps them.
Positioning is cleared here too, and it is the one thing this page does that isn't just removing markup: where a line sits is a property of the whole event rather than a range over its text, so a positioned line goes back to wherever its named style places it. That is what makes the output genuinely plain. The named stylesheet itself is left alone — a cue whose style is bold still looks bold, because the boldness belongs to the style rather than to the text.
One code stays, and the page says so rather than letting you find it: a nine-cell alignment such as `{\an8}` is preserved as written. It encodes vertical placement as well as horizontal, and the tool's own idea of alignment only covers left, centre and right, so there is nowhere to keep the other half. Half-understanding it would mean a file that round-trips wrong. Nothing is uploaded; a file with nothing to remove comes back byte for byte.
Examples
Styling and a leftover effect block
Input
[Script Info]
Title: fade
[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&H00FFFFFF,0,0,0,0,100,100,0,0,1,1,1,2,10,10,10,1
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:01.00,0:00:02.00,Default,,0,0,0,,{\fad(500,500)}{\i1}hello{\i0}
Output
[Script Info]
Title: fade
[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&H00FFFFFF,0,0,0,0,100,100,0,0,1,1,1,2,10,10,10,1
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:01.00,0:00:02.00,Default,,0,0,0,,hello
`{\fad(500,500)}` asks the player to fade the line in and out over half a second each way. The tool never modelled it, so it sat in the text until this run swept it — and the italic pair beside it goes the same way, leaving the line itself. Nothing in the output records that the fade was ever there.
A positioned line
Input
[Script Info]
Title: position
[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&H00FFFFFF,0,0,0,0,100,100,0,0,1,1,1,2,10,10,10,1
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:01.00,0:00:02.00,Default,,0,0,0,,{\pos(100,200)}hello there
Output
[Script Info]
Title: position
[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&H00FFFFFF,0,0,0,0,100,100,0,0,1,1,1,2,10,10,10,1
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:01.00,0:00:02.00,Default,,0,0,0,,hello there
The line is no longer told where to sit, so it falls back to wherever the style named on the event places it. This is the one part of the run that is not simply removing markup, and it is why the page is the right one for a file that has to become plain rather than merely unemphasised.
A nine-cell alignment that stays
Input
[Script Info]
Title: alignment
[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&H00FFFFFF,0,0,0,0,100,100,0,0,1,1,1,2,10,10,10,1
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:01.00,0:00:02.00,Default,,0,0,0,,{\an8}hello there
Output
[Script Info]
Title: alignment
[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&H00FFFFFF,0,0,0,0,100,100,0,0,1,1,1,2,10,10,10,1
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:01.00,0:00:02.00,Default,,0,0,0,,{\an8}hello there
This one comes back unchanged, and that is not a miss. `{\an8}` says top and centre at once, while the tool's alignment covers only left, centre and right — so the vertical half has nowhere to live, and the tag is preserved whole rather than half-understood. The position code is cleared, this one is not.
Frequently asked questions
Why does a nine-cell alignment tag survive this page?
Because the tool cannot represent it exactly. An alignment such as `{\an8}` names one of nine cells, which encodes a horizontal position and a vertical one at the same time, while the tool's own alignment only has left, centre and right. Storing the horizontal half and dropping the other would make the file round-trip wrong, so the tag is preserved verbatim. The position code is cleared, the alignment code is not, and the page tells you that rather than leaving you to notice it.
What is an override block, and why is it in the text?
It is a set of instructions written inside a line's text, between braces, that tells the player to do something to that line: change the styling, animate it, fade it, move it. The tool models the common styling subset and reads those into its own structure, but it leaves the rest exactly where it found it — fades, moves, blurs and the like are kept verbatim rather than discarded, because discarding markup the reader does not understand would be losing data silently. This page is where they finally go.
Does clearing the override codes change the timings or the text?
No. The words come back byte-identical, every cue keeps its start and end to the millisecond, and the order of the cues is the file's own. Line breaks inside a cue are part of the cue rather than part of its styling, so they stay where the file put them. What changes is the instructions around the words, and in some cases where the line sits on screen.
Will the output still play correctly after the codes are gone?
Yes, and more predictably than before. An override code that a player does not understand is at best ignored and at worst mis-parsed, and different players disagree about the effect codes in particular. Plain timed text has no such ambiguity. If the file was relying on positioning to place a caption over something specific in the shot, that placement is gone and the line will sit where the style puts it.
Does this remove the named styles from the stylesheet as well?
No — the stylesheet and the style each cue points at are left exactly as they were. The page works on the codes written inside the text of a line, and a cue whose named style is bold keeps looking bold afterwards, because the boldness comes from the style rather than from the line's own text. Cleaning out a stylesheet is a different job and there is no page for it yet.
Can I use this page on an SRT file, or only on ASS and SSA?
You can drop any of the formats the site reads into it. On an SRT or WebVTT file the first half still does its work — the styling ranges go — and the sweep simply finds nothing, since brace blocks do not occur in those formats. A file that has neither styling nor brace blocks comes back byte for byte, which is the honest result of a run with nothing to do.