What this page is for
This page exists so you can leave with a file.
A youtube transcript download here means two browser downloads: a .txt named after the video ID, and a .srt named the same way when timed events exist.
The words still come from a caption track that already sits on the video. Nothing is invented in the file.
Which file a program can actually open
TXT is one UTF-8 text blob. It has the caption events in order and no clock.
Open it in a plain-text editor, a notes app, or anything that only wants words.
It will not drive a subtitle renderer, because there are no cue numbers and no --> times.
SRT is a SubRip document: cue index, a start and end on one line, then the text, then a blank line. A subtitle file reader, a caption previewer, or a video editor that places cues on a timeline can load that shape. A youtube srt download is the file you want if the next step is “drop this onto a local video,” not “read this like an article.”
I am not listing brand names. I also did not open third-party editors in this run, so I am not claiming a compatibility matrix I did not measure. What I did measure is the bytes this page would put in each file, using the same join-and-timestamp steps the download buttons use.
Where the SRT clock comes from
The milliseconds are not guessed from the soundtrack on this page.
Each caption event arrives with startMs and durationMs from the timed caption track.
The browser then formats start as HH:MM:SS,mmm and formats end as start plus duration (or plus 3000 if a duration is missing).
That addition happens here. The raw millisecond fields do not.
On one track I pulled through this site, the first event had startMs 80 and durationMs 3760.
The SRT cue this page would write is 00:00:00,080 --> 00:00:03,840.
80 + 3760 = 3840, which is 3 seconds and 840 milliseconds. That match is from the numbers, not from a second clock.
On the same file, 8614 of 8721 cues overlapped the next cue: the previous end was later than the next start. That overlap is in the downloaded SRT. It is not cleaned up before save.
Is the saved file line-by-line or one block?
Neither file is a single wrapping paragraph. TXT inserts a blank line between caption events, so event count and nonempty line count match, and the total line count is about twice that because of the blanks. On the long track below, 8721 events became 8721 nonempty TXT lines and 17441 lines counting blanks (2 × 8721 − 1 = 17441).
SRT is stricter: one cue is an index line, a time line, a text line, then a blank line. 8721 cues became 34884 SRT lines. A youtube subtitles download in SRT form is therefore many short cues, not one essay. If two events held the same words, both cues are still in the file.
How large a long caption file got
I ran this site’s caption endpoint on a long, captioned upload and built both files with the same rules as the buttons. Counts from that run:
- 8721 caption events
- TXT: 295849 bytes, 17441 lines, 8721 nonempty lines
- SRT: 599978 bytes, 34884 lines, 8721 cues
- First cue start 80 ms; last cue start 19325280 ms
19325280 ÷ 3600000 = 5.368 hours of timeline, as a division of the measured startMs, not as a separate clock. SRT was larger than TXT on this sample (599978 vs 295849 bytes) because every cue repeats index and time lines. Two more captioned uploads, built the same way in the same run:
- 4953 events; TXT 160776 bytes / 9905 lines; SRT 333025 bytes / 19812 lines; last cue start 8920000 ms
- 2945 events; TXT 112648 bytes / 5889 lines; SRT 214617 bytes / 11780 lines; last cue start 8719830 ms
I am not averaging those three sizes into a typical file. They are three observations, not a model.
Copy is not a file
Copy writes the same TXT string to the clipboard. It does not create a .txt on disk.
Download TXT creates a Blob with type text/plain;charset=utf-8 and a filename of the video ID plus .txt.
Download SRT uses type application/x-subrip;charset=utf-8 and .srt.
Those types and names are what the buttons request in this browser. I did not inspect a second browser’s download manager.
SRT times use a comma before the milliseconds, not a period: 00:00:00,080 on the first long-file cue.
Cue numbers start at 1 and count up in file order. There is no separate header line at the top of the SRT.
When the download never starts
Download TXT and Download SRT live inside a result block that stays hidden until a transcript is on screen. If Get transcript fails, that block never opens, so there is no file to click. The status line above the form is what you get instead.
I hit that path on this origin with several IDs. HTTP status was 200. The JSON error field, shown in the status line, was:
“This video cannot be played here, so there is no caption track to read. Try a public watch page that opens in YouTube.”
That is the failure text I actually received, not a screenshot from another tool.
Other failure sentences this origin already uses (no usable caption track; YouTube refused this request; that input is not a YouTube link or video ID; the caption track came back empty) would also keep the download buttons hidden, because they are the same result block. I did not click Download on a hidden button; there is nothing to click until the result is shown. When a timed track does arrive, both download buttons are enabled. I did not find a success in this run where TXT existed and SRT was disabled.
FAQ
Do I need an account to save the file?
No. The file is built in your browser from the caption events already on screen.
What is the filename?
The video ID plus .txt or .srt. If an ID is missing, the fallback name is transcript.txt or transcript.srt.
Is the file kept on this site?
No. This page does not create accounts or store past downloads.
If you want the clicks written out, see how to get a transcript of a youtube video.