ASS → SRT
Convert ASS or SSA subtitles to SRT so a TV, set-top box or older player can read them. Runs in your browser, and lists exactly what the styling loses on the way.
Runs in your browser
Negative makes the subtitles appear earlier. Cues that would go before zero are clamped to zero rather than dropped.
Not carried across
Parsed and written in your browser. The file is never uploaded.
What you are giving up, stated first
ASS is not a subtitle format with styling bolted on. It is a typesetting format, and the styling is most of what it is for. SRT has a start time, an end time and some text, and that is the entire specification.
So this conversion is lossy by nature, and worth doing only because the thing you want to play the file on cannot read ASS. Everything below survives in the file you started with — keep it.
| ASS carries | In SRT |
|---|---|
| Fonts, sizes, colours, outlines, shadows | gone |
Positioning — {\an8}, {\pos(…)}, {\move(…)} | gone |
Karaoke timing — {\k}, {\kf} | gone |
| Rotation, scaling, clipping, drawing commands | gone |
Per-line styles from [V4+ Styles] | gone |
| Dialogue text and timing | kept |
The page lists what your actual file contained, rather than this general warning.
Why you would do it anyway
Fansubs ship as ASS because signs, songs and overlapping dialogue need it. Almost nothing outside a computer can play it:
- Smart TVs and set-top boxes read SRT and mostly ignore ASS, or render it as raw text including the override tags.
- Plex and Jellyfin can play ASS, but doing so forces a transcode to burn the subtitles in. SRT direct-plays.
- Uploading somewhere. Most platforms that accept a subtitle file accept SRT and WebVTT.
If the target is a computer, install mpv or VLC and keep the ASS. That is a better outcome than this page.
What gets read out of the file
Only the [Events] section, and only Dialogue: lines within it. The Format: line above them
names the columns, which matters more than it looks: Text is the last column and the only one
allowed to contain commas, so splitting a Dialogue: line on every comma cuts subtitles in half
at the first one. The column names are read rather than assumed.
Inside the text, three things are handled:
{…}override tags are removed, not passed through. A converter that leaves them in produces subtitles reading{\an8}Look out!, which is worse than losing the positioning.\Nbecomes a real line break, and so does\n.\hbecomes a normal space.
Comment: lines are not dialogue and are skipped.
Two things to check afterwards
Timing gets no more precise. ASS timestamps are centiseconds — 0:01:02.50 — and SRT is
milliseconds. Every converted time therefore ends in a zero. That is not a rounding bug; the
information was never in the file. Ten milliseconds is under a frame at any frame rate, so it
changes nothing you can see.
Overlapping lines stay overlapping. ASS routinely shows two things at once — a sign at the top and dialogue at the bottom — and keeps them apart by position. SRT has no position, so both cues just overlap in time, and what a player does with that is up to the player: stacked, on top of each other, or one of them dropped. Typesetting-heavy episodes are where this shows.
If a sign is unreadable afterwards, that is this, and it is not fixable in SRT.
If the subtitles are also out of sync
The full converter shifts the whole timeline by a number of seconds at the same time as converting. A constant shift fixes a constant offset; subtitles that drift further out as the episode goes on are a frame-rate mismatch — usually 23.976 against 25 — and shifting cannot fix that.
Related
SRT to WebVTT for putting the result on an HTML <video>, or the
full subtitle converter for every combination and the timeline shift.