Convert SUP (PGS) to SRT
The first run downloads the text reader — about 4 MB plus the language model, served by this site and cached by the browser afterwards. Nothing is uploaded, and the result is machine-read: proofread it before you rely on it.
Options
A bitmap subtitle is a picture of text, so the words have to be read back out of it. Tell the reader which language it is looking at — the list covers every language this site is published in. Pick the one the subtitles are actually written in: Russian subtitles read with the English model come out as noise, not as Russian. Only the model you pick is downloaded (the others never are), so switching costs one download per language, cached afterwards.
A .sup file is a PGS stream, the picture subtitle format Blu-ray discs use. There is not a single character in it: each subtitle is stored as a bitmap, together with a palette and the moment it is meant to appear, and a player composites it over the video. Getting text out of one therefore means reading the letters in each picture. This page does that in the tab with an OCR engine the site serves itself, and writes the result as an .srt file.
The format is a sequence of segments, each with a thirteen-byte header that carries a presentation timestamp in 90 kHz units, a type and a length. Four types matter: the palette definition (PDS), which maps index values to full RGB through YCbCr; the object definition (ODS), which holds one run-length-encoded bitmap; the presentation composition (PCS), which says which objects sit where on the frame; and the display set that stacks them. A cue's start is the timestamp of the display set that shows it. A PGS stream carries no end time at all — a subtitle stays on screen until the next display set replaces it — so the end of each cue here is the start of the next one, which is exactly what a player does.
Because every cue is read by machine, the text is a reading and not a transcription: a serif face at a small size, an unusual font or a heavy outline can turn a character into a different character. Proofread the file before you rely on it. That caveat is not boilerplate — it is the one place on this site where the output is not derived from what the file said, and the page says so rather than presenting the result as exact.
Choose the language the subtitles are actually written in. Each model reads its own script, and the list covers every language this site is published in. Running an English model over Japanese subtitles produces noise rather than a bad translation, because the recogniser is looking for shapes that are not there. Only the model you pick is downloaded, and it is cached afterwards.
Cues whose pictures produce no text at all — a fade frame, a logo, a black cue — are left out and counted in the loss list rather than written as empty lines. Everything that was an image stays an image in spirit: font, colour, outline and on-screen position do not exist in an .srt, and the loss list says so once for the whole file.
Frequently asked questions
What is inside a .sup file that makes SRT conversion a recognition job?
Segments, not characters. Every subtitle in a PGS stream is an object: a run-length-encoded bitmap of palette indices, plus a palette definition that turns those indices into RGB. The only text-like values in the file are the presentation timestamps, which are 90 kHz integers rather than anything a person reads. Converting that to SRT means putting each bitmap on a canvas and recognising the letters, which is why the result needs proofreading and why the page asks which language the subtitles are in.
Why does the last subtitle in the output end a couple of seconds after it should?
Because PGS never says when a subtitle ends. A player shows a composition until the next one arrives or until the stream is cleared, so the only end time that exists in the file is 'the start of the next one'. For the final cue there is no next one; the page gives it two seconds and records that choice in the loss list. If the disc really did leave its last line up for ten seconds, the honest fix is a shift or a duration edit, not a guess hidden in the converter.
Which language model should I pick for subtitles with both Japanese and English lines?
The one the majority of the dialogue is in. A PGS frame can mix scripts in a single line — a Japanese sentence with an English loanword typed in Latin letters is common — but the recogniser is given one model per run, and a model trained on one script reads the other as garbage. If the file genuinely alternates between two scripts, run it twice, once per language, and keep the lines each pass got right: the output is a plain .srt, so merging the two is a diff, not a re-export.
Are the colours of the subtitles carried over into the SRT?
No, and they cannot be. A .sup encodes colour three times over: in the palette (which is YCbCr with an alpha channel, per cue), in the composition (where the bitmap sits on a 1920×1080 frame) and in the outline and shadow drawn into the bitmap itself. SRT has none of those slots. The page reads the luminance of each pixel to decide what is ink and what is background, which is all OCR needs, and the loss list reports styling once for the file rather than pretending the colours survived.
Some cues came out empty or missing. What happened to them?
A picture that produced no text was dropped rather than written as a blank subtitle. That happens with fade-in and fade-out frames, with cues that are only a logo or a symbol, and with very small text below the size the recogniser can resolve. Each one is counted in the loss list, so the file you get is not silently shorter than the file you gave. If the count is high, the usual cause is the wrong language model or a stream whose bitmaps are unusually small.
Does the .sup file or its pictures get uploaded anywhere?
No. The recogniser runs in the tab, and its worker, WebAssembly core and language model are all served from this site and cached by the browser. The only requests the page makes are for those files. That matters more here than on a text page: a PGS stream extracted from a disc is often the one piece of material a studio or a lawyer is least willing to hand to a third party, and the whole point of this page is that they do not have to.