Extract Subtitles from Video
The first run downloads the subtitle engine — about 31 MB, served by this site and cached by the browser afterwards. The video itself never leaves this tab.
This page takes a video file and gives you back the subtitle tracks that are already inside it, one file per track, named after the track's language. A Matroska file with an English SDH track, a Chinese track and a PGS image track comes out as three files: an .srt, another .srt and a .sup. The container is demuxed rather than re-encoded, so a text track is copied out as the bytes that were already in the file — not re-typed from a screen, not re-timed.
The work happens in the tab. The video is read by a build of ffmpeg compiled to WebAssembly that this site serves itself, and the only network request is for that engine: about 31 MB the first time you use the page, cached by the browser afterwards. The video itself is never sent anywhere, which is the same rule every other page here follows and the reason this one can be used on material that is not allowed to leave the machine.
Subtitles that are burned into the picture cannot be extracted, and no tool can do it, because there is no track to read — those words are pixels. If the file has no subtitle stream at all, the page says so instead of producing an empty file, and that includes the burned-in case: a video with visible subtitles and no subtitle track will be reported as having nothing to extract.
The page lists every subtitle stream it finds before it writes anything: index, codec, language, title, and whether the stream is marked default or forced. Tracks that already live in their own container keep their own format — ASS stays ASS, WebVTT stays WebVTT — because converting them to SRT here would silently drop styling, and dropping styling without being asked is the one thing this site does not do. A track whose codec has no standalone container (the mov_text track inside an MP4, for instance) is re-encoded to SRT, and the result card says so rather than letting it pass as a copy.
Bitmap tracks come out as pictures, not text: a PGS stream becomes a .sup and a DVD stream becomes a .sub. That is deliberate — the picture is what was in the file, and guessing at its text is a separate job with its own page and its own language question. Take the .sup to the PGS page if you need text.
Frequently asked questions
Which video containers can I drop in?
MKV, MP4, M4V, AVI, MOV, TS, WebM, WMV, FLV, MPG and OGV. The list is really a list of demuxers that the bundled ffmpeg build has, not a list of video codecs: whatever is inside the container, the subtitle tracks are the same kind of stream. A file with an unusual extension but a normal Matroska body usually still works, because the demuxer reads the header rather than the name; a fragmented or incomplete download often does not, because there is no index to walk.
Does the video leave my computer while it is being read?
No. The only download is the ffmpeg engine itself, about 31 MB, served from this site and cached by the browser after the first use. Your video is mounted into the engine's virtual file system in the tab and read from there; it is never written to a request body. You can confirm this in the Network panel: while a file is being processed there is no request carrying it. That property is the reason the page exists at all — most extractors upload first, and material under a legal or medical hold cannot be uploaded.
Why did I get a .sup file instead of an .srt?
Because that track is stored as pictures, not as text. PGS streams (codec hdmv_pgs_subtitle) are a sequence of images, and the honest extraction of an image stream is an image stream: a .sup, which is exactly what players and subtitle editors expect. Turning it into text means recognising the letters in each picture, which is a different page with a language question and a proofreading step. The extractor never invents text it did not read.
What does the tool do with a track whose format has no standalone file?
It re-encodes that one track to SRT and marks the result as re-encoded. The common case is mov_text, the subtitle codec that lives inside MP4: it has no file format of its own, so copying the stream out would produce bytes nothing could open. Re-encoding is not lossless — styling and positioning that mov_text may carry do not survive — so the result card lists it as a loss instead of presenting the file as an untouched copy of what was in the container.
How are the output files named when there are several tracks?
After the video's own name and the track's language code: a file called documentary.mkv with an English track gives documentary.eng.srt. When two tracks share a language — a normal English track and an English SDH track, which is common — the second becomes documentary.eng-2.srt rather than overwriting the first. A track with no language tag falls back to its stream index, so it is still distinguishable. If you get more than one file, the page offers them as a single zip, because browsers block a page from starting several downloads at once.
Why does the first run take longer than the second?
The first run downloads the ffmpeg engine, about 31 MB. The progress line covers that download and then the extraction itself. The browser caches the engine, so later runs on the same page start almost immediately; the same is true after a reload if the cache has not been cleared. The engine is served in four pieces because the hosting platform refuses individual files over 25 MiB, and the page assembles them in memory before starting — that reassembly is part of the same first-run wait.
Can I cancel a run that is taking too long?
Yes. The cancel button stops the running extraction and terminates the worker that is doing it, so a large file does not keep a core busy after you have decided not to wait. Cancelling is not an error: the item goes back to a state you can retry from, and the next run starts a fresh worker. Nothing partial is offered as a download, because a half-written subtitle file that looks complete is worse than no file at all.