YouTube Transcript 100% in-browser

YouTube Transcript Generator

A transcript generator for YouTube — free, no account, no run limit, nothing uploaded.

Yes — free, with no accounts, counters or uploads.

  • No account, no counter — nothing is metered, so nothing counts your runs.
  • Reads the audio, not captions — a video with no captions still works.
  • You bring the file, and SRT/VTT export is included.
  • Every line is timestamped — so you can check it.
  • Noise changes the text — measured. 4K and vertical cannot — also measured.
  • No speech in the file? It says so — never an empty box.

No box here fetches a YouTube URL — why.

Drop a video or audio file here

or

MP4 · MOV · WEBM · MP3 · WAV · M4A · OGG · AAC · FLAC — any video or audio, not just YouTube

What this YouTube video transcript generator does

It takes a video or audio file that is already on your device — the MP4 you exported from your own upload, a screen recording, a voice memo, a downloaded audio track — finds the speech in it, and writes the words out as text with a timestamp on each line. From that same transcript you can export SRT or VTT subtitle files, which is what you want if the transcript is going onto a video rather than into a document.

The engine is OpenAI's Whisper, running locally through WebAssembly. There is no server behind this page, which is the single most important thing to know about it, because it decides both what it can do for you and the one step it cannot do.

Why there is no link box that fetches the video

Nearly every other tool in this category accepts a YouTube URL and returns a transcript. They can only do that because they run a server: the server downloads the video on its own machine, extracts the audio, transcribes it there, and sends you the text. That is a real capability, and it is also the reason those tools need your link, and the reason your video passes through someone else's computer.

This page deliberately has no server. It cannot fetch a video, and it will not pretend to. A URL box that looks like it fetches while quietly posting your link to a backend would be worse than saying this plainly — so the box above tells you the truth and points you at the file drop instead.

The trade-off is worth stating without spin: you have one extra step — getting the file onto your own device — and in exchange nothing about the video or the transcript ever leaves it. No upload, no queue, no retention policy to read, no account, and no copy of your file on someone else's disk.

What a link-based generator is really reading

This is worth knowing before you compare tools, because it decides what you actually get. When a tool takes a YouTube URL and hands back the text of a two-hour video in a few seconds, the odds are it is not transcribing anything. It is fetching the caption track YouTube already generated for that video and reformatting it — which is exactly why it is instant, and why it costs the operator nothing to run. Some of the largest sites in this category do say so in their own small print: captions fetched, cleaned up, handed back. The headline at the top of the same page usually still promises a transcript "from any video".

The shortcut is honest work, and for the common case it is fine. But it has three consequences, and the pages selling the shortcut rarely spell them out.

There is a quick way to tell which kind of text you were handed. If an hour-long video came back in seconds, if the text carries no punctuation beyond what YouTube's own caption panel shows, and if the line breaks fall on the same phrases as that panel, you are holding a reformatted caption file. If instead the tool made you wait, with a progress bar that scales with the length of the recording, something was actually transcribing the sound.

This page is the second kind, for a reason that is a little different: it never talks to YouTube at all. It has no caption track to read, because it has no link to follow. The file you drop in is decoded here, the audio is separated here, and Whisper runs on that audio here. So the three cases above simply do not arise. A video with captions switched off transcribes the same as one with them on, and a video whose auto-captions are a mess is precisely the case where reading the sound can do better.

Not a promise, though. Whether audio transcription beats a given caption track depends on the recording — accent, music, crosstalk, how loud the room was — and the only honest comparison is the one you run on your own file. What is guaranteed is narrower and more useful: your text does not depend on whether YouTube happened to caption the video, and it does not change if the caption track is later edited or removed.

And there is a case where a link-based tool wins outright: a long, public video you only want the gist of, with a caption track that is good enough. There, YouTube's own caption panel is free, instant and already open in front of you, and nothing on this page beats it.

What "free" actually means here — and the three questions that settle it anywhere

"Free" is the most repeated word in this category and the least defined one. It is worth a minute, because the same word is doing three different jobs on three different pages, and only one of those jobs describes what you get here.

On this page free is not a pricing decision, it is a structural fact. The transcription runs on your own machine, so there is no per-use cost for anyone to recover and nothing to charge you for later. That single fact produces three things at once: no account, because there is no usage record for an account to be attached to; no counter, because nothing is being metered; and no paid tier, because there is no meter for a tier to sit above.

Three questions that settle "free" on any of these tools

What this page's answers are

Runs: no counter and no cap. Not because a limit was lifted for you, but because nothing on the page is metered — the work happens on your device, and your device does not report to anyone.

Account: none, and no email address either. There is no form on this site that collects one, and no paid tier behind the free one. Nothing to cancel.

What you pay with: your device's processor and memory, plus one download. The first run fetches a Whisper model from this site — 41 MB, 42 MB or 76 MB, depending on which you pick — and the browser keeps it, so later runs do not fetch it again. On a phone that download is the real cost of "free": prefer the smallest model and short clips. The second line item is small, and it is on the privacy page rather than buried: this page carries Google Analytics, which writes two cookies that last two years, and a cookieless Cloudflare view count.

Export: included. TXT, SRT and VTT come out of the same run at no extra step, with no watermark and no "upgrade to download" — there is no payment system on this site for such a button to lead to.

One boundary worth keeping straight: free and unlimited here describe the absence of a meter, not a promise about your hardware. A long recording on a low-memory device can still fail to fit — the decoded audio alone runs to about 176 KB for every second of recording — and the page says so in words. Where it is the model that does not fit, the page steps down to a smaller model and tells you it did. That is a memory ceiling every local transcription tool shares, not a paywall.

How to tell whether the transcript is good enough

Every page in this category sells the same three adjectives — clean, accurate, fast — and none of them tells you how to judge the text you just got. That part is left to you, and it is more mechanical than it sounds, because this page puts a timestamp on every line. Here is what the output actually looks like, and the one habit that catches the mistakes worth catching.

What comes out. Measured on a real run of this page: the text is punctuated and capitalised — full stops, commas, question marks, sentence-initial capitals — and every line begins with its own time in [hh:mm:ss.mmm] form. There is nothing to reformat by hand before the text is readable.

Where the punctuation comes from. This is worth knowing, because it decides how much weight the text can carry. The punctuation is inferred from the words and the pauses between them, not heard in the audio; the model is deciding where a sentence ends, the way a reader would. Run the same sentence twice and you can get a full stop in one pass and a question mark in the other — that is a measurement from this page's own output, not a hypothetical. Read the text as a strong draft, not as a transcript of record.

What the page will not do for you. It will not tell you which words it is unsure about. There is no confidence score and no highlighted word: the model returns one sequence of words, and that sequence is what you get. So the useful habit is not to read the whole thing line by line, but to spot-check the parts that carry meaning — names, numbers, brand names, technical terms. Those are where a speech model is weakest, and also where a wrong word costs you the most.

The reason to spot-check rather than trust the shape of the sentence: when this kind of model gets a word wrong, it usually produces a sentence that still reads perfectly well. In the run measured above, one pass of the same audio read what you should check and another read which you should check — two plausible sentences, one of them not what was said. Nothing in the text flags it. The timestamp does, because it lets you go back and listen.

How to use the timestamp. Each cue starts where the speaker paused rather than at a fixed interval, and you can see that in the timings, which land on 1.9 s, 4.9 s, 9.9 s rather than on the round numbers a fixed interval would produce — with one exception, the 15-second ceiling described below. That detail matters more than it looks: a tool that cuts on a fixed interval puts its line breaks wherever the clock happens to be, without asking whether the speaker had stopped, which makes the transcript harder to read and clumsier to re-use as subtitles. This page asks first and cuts second: it looks for the last quiet moment between 8 and 15 seconds into each piece and takes that, with the ceiling above it. So a line follows the speaker's pauses, but it is not guaranteed to be a whole sentence — when the speech never goes quiet, the ceiling wins and the cut lands mid-sentence. The measured numbers are in the section on cue times below.

Two honest boundaries. This page does not edit the transcript for you and offers no correction interface — you fix the words in your own editor, and the export buttons give you the result in whichever format you need. And no accuracy percentage is printed here or anywhere on this page, for the reason set out further down: it depends too much on the recording to be one number. What you can rely on instead is that the mistakes are findable, because you can always go back to the second they came from.

Is the transcript what you said, or a tidied-up version of it?

Every page in this category promises text that is "clean". Not one of them says what clean does to the way people actually talk — the ums, the false starts, the word that gets said twice. That sounds like small print and it is not: if you are transcribing an interview, a research session or a documentary, whether the fillers are in the text or out of it decides whether the file is any use to you.

Measured on this page, on one file. A clip was recorded saying, out loud: "Um, so, uh, I was going to say that, you know, we were going to launch it on March 3rd, 2026, and, uh, the the budget was 1,250 dollars. Uh, and, you know, roughly 20 percent of that was already spent." That audio was then put through this page with the default model.

What came back: "So I was going to say that, you know, we were going to launch it on March 3rd, 2026 and the budget was $1250. And, you know, roughly 20% of that was already spent." Four things changed on the way through, and none of them is a mistake.

So the honest description of the output is this: it is a readable rendering of what you said, not a word-for-word record of it. It has been tidied in the direction a writer would tidy it. For notes, an article, a summary or a set of subtitles, that is exactly what you want. For a verbatim record — a deposition, an interview you intend to quote word for word, a language study — it is not, and the time to know that is before you rely on the text rather than after.

The model you pick changes what survives, and that was measured too. The same file, on the same page, run with whisper-tiny.en instead, comes back as "So, uh, I was going to say that, you know, ... and, uh, the budget was $1,250. Uh, and, you know, ..." — three of the four fillers are back, and the word count is 37 against 34. Two texts, one file, and the whole difference between them is the "uh"s. The numbers stayed digits in both, though the amount was punctuated differently: $1250 from the default model, $1,250 from the smaller one.

What to do about it. If what you want is a readable version, the default is doing the right thing and there is nothing to fix. If you need the fillers — because the hesitations are part of what you are studying — run the smallest model and compare the two texts. That is the cheap experiment, and on this file it was the one that kept them. And check the numbers yourself, whichever model you used: a date or an amount is the hardest change to notice, because the digit version does not look wrong. It looks better than what was said.

Boundaries, stated rather than glossed over. This is one file and two models, so treat the filler behaviour as model-dependent and probably audio-dependent as well — the only test that settles it is your own clip. There is also nothing in the output that flags a change: a dropped "uh" is not an error, so it is not marked, and no confidence score would surface it. On repetition: this file transcribed identically on two consecutive runs of the default model, all 34 words and both cues, which means re-running for "a better pass" gets you the same pass — but on a different clip we have seen the punctuation land differently between two runs of the same audio, so do not assume either way. If the text matters, run it twice and compare.

What the generator does with the parts that are not speech

A page in this category will happily tell you how clean and accurate its output is. What none of them covers is the case where there is nothing to transcribe at all — and that is the failure a user is most likely to meet, and the hardest one to read, because you get either nothing back or something that was never said, and no page tells you which of those two means the tool is broken.

Measured on this page. Four silent inputs were put through the tool: ten seconds of digital silence, ten seconds of one steady tone, ten seconds of quiet room noise, and a video file whose audio track is missing entirely. All four came back with the same sentence — No speech found in this file. It may be silent, music, or too quiet to make out — check that the clip has audible talking, then try again. None of them produced an output panel, and none produced a single word of text. Each run ended in two to seven seconds. A steady tone is not the same test as music, though. A real music bed at normal level passes the level check, and on 2026-10-17 an eighteen-second bed with no voice in it came back as a bracketed marker plus a line nobody said — so the first cue is worth reading on any file that opens with music.

Why that check exists, and why it is the interesting part. A speech model asked to read a stretch of silence has nothing to read, and what it produces in that situation is words that were never spoken: a plausible sentence, a caption-shaped line, sometimes the same line repeating. It is among the most common complaints from people who run these models on their own recordings, and the usual workaround is to cut the silent stretches out of the audio before transcribing. This page checks instead. Before that check existed, it did the other thing and invented a transcript for silent audio, because the alternative was an empty panel with a green "Done" on it — and an empty panel looks exactly like a page that has stopped working. Both of those are worse than one sentence that tells you what happened.

The other half: silence inside a file that does have speech. This is the case people actually meet, because real recordings have gaps in them. Measured on a 19.5-second clip whose talking stops at 6.5 seconds: the transcript holds one cue, at 0:00, carrying the sentence, and then nothing at all for the remaining thirteen seconds. No filler cue, no marker, no line stretched out to the end of the file. A gap in the audio becomes a gap in the transcript, and the timestamps stay pinned to the recording.

That last detail is worth more than it sounds when the transcript is going onto a video. A cue that spans a silence is a subtitle that stays on screen after the speaker has stopped, which is the most visible kind of bad captioning there is. Here a cue ends where the speech ends, because there is nothing else for it to cover.

If you meet invented text in a transcript from somewhere else, the timestamp is what settles it. Find the line, play the audio at that second and listen. If nobody was speaking, those words did not come from your recording — they came from a model reading silence, and the practical fix is to trim the silent stretches out of the audio and run it again.

One boundary: this check detects speech, not language, and it says nothing about how clear the speech is. A recording that is genuinely too quiet or too muffled to make out gets the same message as silence does, so raise the level and try again before concluding the tool failed. And the check is about whether there is speech at all, not about whether the words are right — that part is still the timestamp's job, in the section above.

What happens when the audio is hard for a machine to hear

Every page in this category will tell you its tool is accurate. None of them tells you what happens to that accuracy when the recording itself is the problem — background noise behind the voice, a speaker talking fast, two people overlapping, a thick accent, music mixed louder than the words. That is the gap, because those are exactly the recordings people bring to a transcript generator, and the text you get back changes with every one of them.

Measured on this page. One clean sentence was spoken by a synthetic voice and saved as an audio file: Dr. Margaret Chen from Stanford University announced a budget of forty seven thousand dollars for the quantum computing laboratory renovation, scheduled for November fifteenth, twenty twenty six. The file was run through the tool three ways, with no editing between runs.

Clean audio, smallest model. The transcript came back at twenty-two words with every proper noun intact — Margaret, Chen, Stanford — every technical term — quantum, computing, laboratory, renovation — and all three numbers correct: $47,000, November 15th, 2026. Nothing was dropped and nothing was invented.

Background noise added at 35%, smallest model. White noise was mixed into the same recording at a level a real kitchen or a moving car might produce, and the text fell apart. "Margaret Chen" became "Marsha's 10." "Stanford University" became "San Francisco University." "Quantum computing laboratory renovation" became "quarantine, including loud before we go to the base of this." Four out of four proper nouns were wrong. Four out of four technical terms were wrong. Only the dollar amount survived, and the date was lost entirely — the model heard "the end of 2015" where nothing of the sort was spoken.

Same noisy file, larger model. Switching from whisper-tiny.en to whisper-base recovered most of what the smaller model lost. "Margaret" came back, though "Chen" was written as "Ten." "Stanford University" returned correctly. "Computing laboratory renovations" returned — the word "quantum" was dropped, but the rest of the technical phrase survived. Three of four proper nouns and three of four technical terms were now right, where the smaller model had zero of each.

Heavier noise, 60%. At a noise level that makes the speech hard for a person to follow, the tool's own speech check fired before any text was produced: No speech found in this file. It may be silent, music, or too quiet to make out. The same gate that catches silence catches a recording buried in noise — and it tells you so rather than inventing words.

What to take from this. Three things, and none of them is "buy a better microphone," because that is obvious and not always possible. First: the model you pick matters more than the tool you pick — the same file, the same page, the same noise, and whisper-base recovered proper nouns and technical terms that whisper-tiny.en lost entirely. If the recording is less than clean and the text matters, switch to whisper-base before you conclude the tool failed. Second: proper nouns, brand names and numbers are the first things to go when the audio degrades, so those are the lines to spot-check against the timestamps — a wrong name in a transcript is the error most likely to leave the page unnoticed. Third: if the tool returns nothing at all and says the file has no speech, that may be true — a recording with heavy background noise can fall below the speech threshold even when someone is clearly talking. Raising the audio level or trimming the noisy parts before trying again is the fix, not a different tool.

The measurement above used synthetic speech mixed with generated white noise, which is a controlled approximation of real-world degradation rather than a field recording. Real background noise is not uniform, real accents are not synthetic, and real overlapping speech is messier than any single test can capture. The direction of the result — noise degrades proper nouns and technical terms first, a larger model recovers some of what a smaller one loses, and very heavy noise trips the speech gate — is the finding worth carrying, not the exact percentages.

When you do not need this tool at all

Worth checking before you spend time on it: most YouTube videos with speech already carry a caption track, and reading it may be all you need. Reach for this page when one of these is true instead.

How to get the video file in the first place

This is the step the other tools hide from you, so here it is plainly. If the video is yours, YouTube Studio offers a download option on your own uploads — that MP4 is exactly the file this page wants. If you already have the audio as a separate file, use that instead: it is smaller, uploads faster and transcribes identically, because the audio is all this page ever looks at.

If the video is not yours, YouTube's terms do not allow downloading it, and this page is not a way around that. Where a video already has captions, reading them is the intended route. Where you have a copy legitimately — the creator sent you the file, you recorded the call, you were given the footage — drop it in and it will transcribe the same as any other file.

Where the transcription model comes from

Three Whisper models are stored on this site and served from this site's own address: whisper-tiny.en (41 MB, English only), whisper-tiny (42 MB, multilingual) and whisper-base (76 MB, multilingual, the default). The browser downloads one of them on the first run and caches it; every run after that starts from the cache (measured on this page: a first run in a fresh browser fetched nine model files, and running the same page again fetched none).

That detail sounds like plumbing. It is not. Most in-browser transcription tools pull their model weights from a third-party model host on first use, which means the tool only works if that host is reachable from your network — and there are networks, including many mobile networks, where it is not. Here the weights come over the same domain as the page you are already reading. If this page loaded, the model will download.

Because the weights are cached, the network stops mattering after that first run. That was measured by switching the network off: the same clip came back byte-identical to the online run, and the browser attempted no requests of any kind while it ran. The page is the exception — it is not served from the browser's cache, so it has to be loaded with a connection every time and then left open. The offline window is that open tab, not a page you can come back to later.

The dropdown also lists whisper-small, which is not stored on this site. It is roughly 240 MB, which is too large for this site to host, so it has to come from the third-party host and may not be reachable from where you are. If you pick it and it cannot be fetched, the run stops and says so, naming the model — it does not sit there retrying something that cannot succeed. If you want accuracy above whisper-base, the honest options are a desktop machine on an unrestricted network, or accepting base.

What you get out: TXT, SRT and VTT

All three files hold the same words in the same order, and only the wrapper around each line changes — measured on a four-cue clip: the word sequence is identical across TXT, SRT and VTT. TXT is plain text, one line per cue, each prefixed with its start time ([00:00:07.636]) — the format to read, quote or paste somewhere else. SRT is numbered cues (1, 2, 3…) with a start and end time on each and a comma before the milliseconds (00:00:07,636). VTT is the same cues without the numbers, with a dot before the milliseconds, opening with WEBVTT. SRT and VTT are the formats to hand to an editor or a platform's caption box, so a transcript you made here can become the captions on a video. Both were checked here against independent subtitle consumers rather than assumed to work.

Cue times come from where the speech pauses: the audio is split at silence, each piece keeps its real span, and one cue ends exactly where the next begins — measured on all three joins of a four-cue clip, with no gap and no overlap. There is a limit sitting on top of the pauses, and it is worth knowing because it is the thing that decides the awkward cases: the audio is cut into pieces of at most 15 seconds, and inside each piece the splitter takes the last quiet moment between 8 and 15 seconds — if the speech never goes quiet in that window it cuts at 15 seconds anyway, wherever the clock happens to land. A file under 15 seconds is never split at all. Two consequences are worth knowing before you publish the subtitles. A cue boundary can fall in the middle of a sentence: on a clip of unbroken speech a cue ended at 00:00:14.840 with the sentence continuing in the next cue, and on a four-cue clip one cue ended at 00:00:15.000 the same way. And the last cue runs to the end of the file rather than to the last word — on a 22.34-second clip whose last word stops at 20.698 s, the final subtitle stayed on screen for the remaining 1.64 s. Neither is a transcription error, but both are visible in the file, so check the cues after export if they matter to you. Both of those boundaries are that same 15-second limit seen from two sides: 00:00:15.000 is the limit itself, when nothing in the window was quiet enough, and 00:00:14.840 is the last quiet frame just before it — measured again on a 23.59-second clip of unbroken speech, where the cut landed at 00:00:14.840 and the next line opened with the continuation of the sentence.

Nothing is transcribed twice. Switching the format button re-cuts the same text into the other wrapper — measured: TXT → SRT → VTT → TXT ran no further audio decode and made no further model request, and switching back returned byte-identical text. The download button gives one file per format, named after the file you dropped in (report.v2.mp3 → report.v2.srt), holding exactly the text on screen — checked byte for byte.

What is actually in the file. Read byte by byte on a 23.59-second clip, the three downloads share three properties that decide whether a stricter tool will take them: none carries a byte-order mark, all three use plain line feeds with no carriage returns anywhere, and none ends with a newline after its last line. The structure is otherwise the standard one — SRT is the cue number, then 00:00:14,840 --> 00:00:23,592 with a comma before the milliseconds, then the text, then a single blank line before the next cue; VTT opens with WEBVTT and a blank line, then carries the same cues without the numbers and with a dot before the milliseconds; TXT is one line per cue, each prefixed with [hh:mm:ss.mmm]. If an editor refuses a file, those three properties are the ones to compare against what that editor says it expects.

Accuracy: what this page will and will not claim

There is no accuracy percentage printed anywhere on this page, on purpose. Whisper's word error rate swings enormously with audio quality, accent, background music, crosstalk and speaking speed, so one headline number would be marketing rather than information — and the material people bring here is often the hard case, since short clips are typically music-backed and spoken fast.

What can be said precisely: the models offered are the official Whisper checkpoints converted to ONNX by the open-source Xenova project, and larger models are generally more accurate than smaller ones. whisper-tiny is the fast option, whisper-base the default, and if a transcript matters, use base and listen back to the parts that look wrong. Proper nouns, brand names and numbers are where every speech model, this one included, is least reliable.

Long videos, phones, and running out of memory

The limit on this page is not video length, it is your device's memory: the whole audio track is loaded into memory before transcription starts, so a two-hour recording on a low-memory laptop can fail where a ten-minute clip on the same machine succeeds. Splitting a long recording into parts is the usual fix, and the parts can be transcribed one after another — but where the cut lands decides whether anything is lost. Measured on this page: one 29-second recording of continuous speech was cut in two at a real pause, and the two halves came back as the same 94 words as the single run; cut at an arbitrary second instead, the two words under the cut appeared in neither half. Cut at a pause, not at a second.

Two behaviours are worth knowing about, because they are what makes a failure here readable rather than mysterious. First, if a run fails because the model did not fit in memory, the page steps down to a smaller model and tries again, then tells you it did — and remembers the step-down on that device, so the next visit does not repeat the whole failure. Second, if the tab is killed outright mid-run — the browser reclaiming memory, the phone sleeping, the app being closed — nothing on the page can report that, because no code runs at all when a page is killed. So the run is marked before it starts and the mark is cleared when it ends — but the mark being there is not, on its own, the question the page asks. A run holds a browser lock for as long as it lives, and that lock dies with the tab; where the browser has no such lock, the mark carries a heartbeat instead. So the next visit asks first whether any live page is still running it, and only when nothing is still running it and the mark is left over does the page say the previous run did not finish, rather than silently starting over. That is what stops a second tab from accusing a run that is still going in the first one.

On a phone, prefer whisper-tiny and short clips. Mobile browsers give a tab far less memory than a desktop, and background tabs are the first thing a phone reclaims.

A slow run and a stuck run look identical from the outside, so the guards here measure progress rather than elapsed time. The progress line names the phase the run is in, and the two guards that end a run both watch the last moment anything actually moved: if a model download stops delivering bytes, the page stops it and says the connection dropped part-way, and if nothing moves at all for twenty minutes the run is given up on. A download that is still delivering bytes is never killed for being slow — it is allowed to finish however long it takes. There is also no stop button on this page: while a run is going, every control is locked so the file cannot be swapped or removed mid-run. Closing the tab is the way to end one, and the mark described above is what makes that recoverable rather than silent.

Does the shape of the video change anything? Shorts, 4K, playlists, live replays

No — not the shape you are worrying about. Resolution, aspect ratio and file size do not touch the text at all. The only property of a video that changes what this page returns is whether the file contains audible speech. Everything else is either irrelevant to the transcript or a question about your device rather than about the video. That is worth saying plainly, because this is the one thing the rest of the category never separates: every other page treats "a video" as a single kind of thing and never tells you which of the differences actually matter.

Measured on this page. One recording, spoken by a synthetic voice, was wrapped in four different containers and each was run through the tool with no setting changed: a 720×1280 vertical file of the shape a Shorts download arrives in, a 1920×1080 horizontal file, a 3840×2160 file, and the audio on its own with no picture at all. Four files, four runs. All four returned the same twenty-four words in the same order, split into the same two cues — character for character identical. The picture, and how much of it there was, changed nothing.

Why: the picture is never decoded. The tool reads the audio track and stops there; the frames are never looked at. The test was built to prove that rather than assert it. Each of the three video files had a different word painted into the picture in large type, and none of those words was ever spoken: MARZIPAN on the vertical file, OBSIDIAN on the horizontal one, TANGERINE on the 4K one. Across all four transcripts the count for every one of those words was zero. If any of the picture were being read, those words were sitting in the middle of the frame, and they never surfaced. Run time did not follow resolution either: once the model was already cached, the 1080p file took 8.0 seconds, the 4K file 7.5 seconds and the audio-only file 6.4 seconds. A 4K frame carries sixteen times the pixels of a 1080p frame, and it made the run no slower.

Shorts. A Shorts download is an ordinary 720×1280 MP4 — it is the vertical file in the test above, and it works with no conversion, no re-encoding and no setting to change. Two things about Shorts are worth knowing, though neither of them is about shape. Shorts are often music with little or no talking, and a file whose audio is music rather than speech gets the speech message instead of invented text — the section on non-speech shows what that looks like. And a Short posted straight from a phone frequently has no caption track at all, which is precisely the case where a caption-fetching tool has nothing to hand you and this page still does.

Playlists. There is no queue here, and that is deliberate rather than pending work. Measured on this page: pick a second file and the result from the first is cleared from the screen — one file is on the page at a time. So a playlist is worked through one video at a time: transcribe, export, pick the next. Nothing runs in the background and nothing is remembered about the files you have already done, which is the same property that keeps the whole thing off a server.

Live replays. A replay stops being a special case as soon as you have it. YouTube writes a finished stream back as an ordinary video file, so once you have the file it behaves like any other file here — and if you do not have the file, nothing on this page can fetch it, for the reason set out above. What is genuinely different about a live recording is not its shape but its content: long stretches with no speech, room tone between speakers, and often a caption track that is missing rather than wrong.

The one limit that is about length, not shape. None of the above should be read as "any size of file works." The constraint on this page is your device's memory, not the video's shape: the whole audio track is loaded before transcription starts, so a very long recording can fail where a short one on the same machine succeeds. That is covered in the section on long videos and memory. Shape, resolution and aspect ratio are not part of that ceiling.

One boundary: these numbers come from one recording on one machine — a desktop browser with the model already cached — so treat the exact seconds as a sample rather than a specification. A phone will be slower, and a phone will also run out of memory sooner. The finding worth carrying is the direction of the result: the picture is never decoded, so its resolution and its aspect ratio cannot change the words you get back, and the only property of the file that does change the outcome is whether there is speech in it.

Supported input formats

Anything your browser can decode. In practice that means the common containers: MP4, MOV, WEBM, MP3, WAV, M4A, OGG, AAC, FLAC. That list is not a filter this page applies — it is a description of what browsers already decode, which is why it is the whole rule rather than a starting point. A container your browser cannot read fails here exactly the way it fails anywhere else, and the page says so in words instead of handing back an empty box.

Both halves of that were measured here rather than assumed. One recording was transcoded into all nine named containers and run through this page: every one decoded, every one came back with the same eighteen words, and every one went through the fast audio decoder rather than the slower real-time reader the page keeps in reserve — so the wrapper changes nothing about the text. Four containers that are not named above were put through the same run: .opus, .mkv, .3gp and .m4v all worked too, while .aiff and .avi did not, and came back with the reason and a next step rather than silence. Video files are the normal case — the audio track is extracted in the browser before transcription, and the picture is never decoded, so resolution and aspect ratio cannot change the text.

How the container list was checked: a single spoken recording was encoded into each container with ffmpeg, keeping the words identical, and each file was dropped into this page on the default settings. Every run was repeated; the nine transcripts were identical to each other and to the previous run, word for word.

Supported languages

The multilingual models (whisper-tiny, whisper-base, whisper-small) auto-detect the spoken language and transcribe in it rather than translating. That is decided one pause-delimited piece at a time rather than once for the file, so a recording that changes language partway through is not written down in both — the measurement is on the podcast page. Whisper's published language list covers 99 languages. The whisper-tiny.en model is English-only. That first sentence is measured here rather than copied from a spec sheet: a Spanish clip, a German clip and a Japanese clip were each run on the default model, and each came back in the language it was spoken in, the Japanese still written in Japanese characters. The same Spanish clip on the English-only model produced 402 words of a single repeated phrase instead — see the FAQ for which model to pick.

Source for the 99-language figure: the Whisper model card published by OpenAI (openai/whisper on Hugging Face), which lists the supported languages and their language codes. Common ones include English, Spanish, French, German, Portuguese, Italian, Japanese, Korean, Chinese, Arabic, Hindi, Russian, Turkish, Vietnamese, Thai and Indonesian.

FAQ

Can I paste a YouTube link and get the transcript?

Not on this page, and that is a deliberate choice rather than a missing feature. This page has no server, so there is nothing that could fetch a video for you, and no public endpoint returns a video's transcript. You bring the file; the transcription then runs on your own device.

Why do some YouTube transcript tools return nothing for a video?

Because most of them are not transcribing the audio at all — they fetch the caption track YouTube already generated and reformat it. No caption track means nothing to fetch, which is why those tools go quiet on a video whose creator left captions off. This page never reads a caption track: it decodes the audio of the file you give it and runs Whisper on that, so a missing caption track is not a failure case here.

Is anything uploaded to a server?

No. The file is read and decoded in the browser, and the Whisper model runs in the browser via WebAssembly. There is no backend to upload to. Four requests leave this browser: the one-time download of the model weights from this site, a cookieless view count reported to Cloudflare Web Analytics, the Google Analytics script this page loads, and the reports that script sends on to Google — the privacy policy lists exactly what each of them is. You do not have to take that on trust, either. Open your browser's developer tools, switch to the Network tab, and start a transcription: no request appears that carries your file, because none is made. What you will see is the model download, two small view-count reports — one sent to Cloudflare Web Analytics, one to Google Analytics — and nothing about your file at all.

You do not have to take that on trust, either. Open your browser's developer tools, switch to the Network tab, and start a transcription: no request appears that carries your file, because none is made. What you will see is the model download, two small view-count reports — one sent to Cloudflare Web Analytics, one to Google Analytics — and nothing about your file at all.

Where does the transcription model come from?

From this site. whisper-tiny.en (41 MB), whisper-tiny (42 MB) and whisper-base (76 MB) are stored on this domain and served from it, so the first run does not depend on any third-party model host being reachable. The browser caches the model after the first download.

Why is the first run slow?

The model weights are fetched once and then cached by the browser. whisper-tiny is 42 MB and whisper-base is 76 MB, so the first run moves tens of megabytes before any transcription starts. That is why the progress line names the size. After that the cached model loads quickly.

Does it work with long videos?

The limit is not length but your device's memory, because the whole audio track is decoded into memory before transcription. That cost was measured on this page: about 176 KB of memory for every second of audio, which is roughly 10 MB a minute and about 1.2 GB for a two-hour recording. A long recording on a low-memory machine can therefore fail, and the page reports that in words rather than leaving a dead button. Where it is the model that does not fit in memory, the page steps down to a smaller model and tries again, tells you it did, and remembers the step-down on that device so the next visit does not repeat the whole failure.

What happens if the recording is too long for my device to hold?

The page says so in words rather than leaving you watching nothing. The failure lands while the audio is being read, not while the model is loading: the model has already been fetched by then, so it is the decoded audio that has to fit. Measured on this page, a 624-second recording run through the page's own decoder produced a 110,073,600-byte audio buffer — about 176 KB for every second of recording, which is roughly 10 MB a minute and about 1.2 GB for a two-hour file. Splitting the recording and running the parts one after another is what works, and the parts can be transcribed one after the other without re-reading the earlier ones. Where the cut lands decides whether anything is lost: measured on this page, one 29-second recording cut in two at a real pause came back as the same 94 words as the single run, while a cut at an arbitrary second left the two words under it out of both halves — so cut at a pause, not at a second.

Does it work on a phone?

The layout adapts down to phone widths, and transcription does run in a mobile browser, but it is heavy work. On a phone, prefer whisper-tiny and short clips. If a tab is killed mid-run by the browser or the system, the next visit says the previous run did not finish rather than silently starting over.

How do I tell whether it is still working, or stuck?

The progress line names the phase, and the phase changes as the run moves: it loads the model first, then names the model file and its percentage as it downloads, then says Transcribing. A bar that is moving is a run that is moving. Two guards end a run that has genuinely stopped, and both say so instead of leaving you watching a frozen bar. If a model download stops delivering bytes, the page stops it and says the download stalled and that the connection dropped part-way. If nothing progresses at all for twenty minutes — nothing on the network and nothing in the transcript — it says the run stopped making progress and suggests a shorter clip or a smaller model. A slow run is not killed: both guards measure progress rather than elapsed time, so a download that is still delivering bytes is allowed to finish however long it takes.

Can I stop a transcription once it has started?

There is no stop button, and that is deliberate: while a run is going, every control on the page is locked, so the file cannot be swapped or removed mid-run — the page says so under the progress line. If you need it to stop, close the tab. Nothing was ever sent anywhere, so there is no server-side job left running, and the next time you open the page it tells you the previous run did not finish rather than starting over silently. The partial result is what you lose: a transcript is not kept between visits.

What are TXT, SRT and VTT?

TXT is plain text with timestamps at the start of each line. SRT is numbered cues with a start and end time on each and a comma before the milliseconds; VTT is the same cues without the numbers and a dot before the milliseconds, opening with WEBVTT. All three carry the same words — measured on one clip, the word sequence is identical and only the wrapper changes. Both are standard subtitle formats, and that they read outside this site was checked rather than assumed: the exported SRT and VTT were handed to four independent subtitle consumers — three parser libraries and ffmpeg — and each read back every cue, with a round trip through ffmpeg keeping every word. If you want to put subtitles on a video, export SRT or VTT rather than TXT.

Are the TXT, SRT and VTT files the same transcript, or three different ones?

The same transcript. Measured on one clip: all three held the same four cues, with the same words in the same order, and only the wrapper around each line differed — TXT prefixes the start time, SRT adds cue numbers and a comma before the milliseconds, VTT drops the numbers and uses a dot. Switching format after a run did not start a second transcription: no further audio decode and no further model request were made, and switching away and back returned byte-identical text. Each download is a file named after the one you dropped in, holding exactly the text on screen.

Will the SRT or VTT open somewhere else?

Yes, and that was checked from the other side rather than assumed. The exported SRT and VTT were handed to four independent subtitle consumers — three parser libraries and ffmpeg — and every one read back all the cues, with a round trip through ffmpeg keeping every word. What is in the file is worth knowing too, because it is what to compare against if a stricter app ever refuses one: no byte-order mark, plain line feeds with no carriage returns, and no newline after the last line.

Will the subtitles line up with the words — one cue per sentence?

Not always, and it is worth checking before you publish them. Cue times come from where the speech pauses, so a cue boundary can land in the middle of a sentence: on a clip of unbroken speech a cue ended at 00:00:14.840 mid-sentence, and on a four-cue clip one cue ended at 00:00:15.000 with the rest of the sentence in the next cue. Both of those are the same 15-second ceiling seen from two sides, and it is worth knowing which is which. The audio is cut into pieces of at most 15 seconds, and inside each piece the splitter takes the last quiet moment between 8 and 15 seconds, so 00:00:15.000 is the ceiling itself — nothing in that window was quiet enough — and 00:00:14.840 is the last quiet frame just before it. Re-measured on a 23.59-second clip of unbroken speech the cut landed at 00:00:14.840 again and the next line opened with the continuation of the sentence. A file under 15 seconds is never split at all. The last cue also runs to the end of the file rather than to the last word — on a 22.34-second clip whose last word stopped at 20.698 s, the final subtitle stayed up for the remaining 1.64 s. Cue times do tile exactly, so nothing is skipped: every cue ends where the next one starts.

How accurate is it?

No percentage is printed on this page, because word error rate depends on audio quality, accent, background music and speaking speed, so a single headline figure would be marketing rather than information. What is precise: the models are the official Whisper checkpoints converted to ONNX by the Xenova project, and larger models are generally more accurate. If a transcript matters, use whisper-base.

Can I transcribe a YouTube video that has no captions?

Yes. Most link-based generators read the caption track YouTube already created, so a video with no captions leaves them with nothing to return. This page decodes the audio instead, so a missing caption track is not a failure case here — if you can get the file onto your device, it can be transcribed.

Does it work on private or unlisted YouTube videos?

This page never fetches a URL, so it does not matter whether a video is public, unlisted or private. What it needs is the file on your device: save or download the video first, then drop it in. Getting the file is up to you and to the permissions on that video — this page has no way to reach it for you.

Can it run without an internet connection?

Once the model has been downloaded and cached by the browser, a transcription run downloads no model weights from the network — the audio decoding and the Whisper model both run locally, and that was measured by switching the network off: the same clip returned a transcript byte-identical to the online run, and the browser attempted no requests at all while it ran. The page itself is the part that still needs a connection, and it needs one every time you open it. This page is not served from the browser's cache, so coming back to it with the network off fails before the tool even loads — measured twice, once after a long session and once immediately after a fresh online load. The offline window is the tab you already have open, not a page you can return to later.

Is this YouTube transcript generator free — any limit or sign-up?

Free, with no sign-up and no limit, and the reason is structural rather than promotional: the transcription runs on your own device, so there is no server usage to meter and nothing to bill. There is no account, no email address and no counter. What you spend instead is your device's processor and memory, plus a one-time model download of 41 to 76 MB that the browser caches afterwards.

Do I have to pay to download the SRT or VTT file?

No. TXT, SRT and VTT all come out of the same transcription run, and the download button works on all three with no watermark and no paid tier above it — this site has no payment system at all. If a tool in this category charges for subtitle export or marks the output on the free tier, that is a product decision on their side rather than a technical one.

How do I check whether the transcript is accurate?

There is no accuracy percentage to check against, and this page deliberately does not print one, because it depends too much on the recording to be a single number. What you can do is use the timestamps: every line starts with the time it was spoken, so you can play the audio at that moment and compare. The habit that catches the most is to spot-check names, numbers, brand names and technical terms, because that is where a speech model is weakest and where a wrong word costs you most.

Does the transcript come with punctuation and capital letters?

Yes. Full stops, commas, question marks and sentence-initial capitals are all there, so there is nothing to reformat by hand before the text is readable. One caveat is worth knowing: the punctuation is inferred from the words and the pauses between them rather than heard in the audio, so sentence boundaries are the model's reading of the recording. Treat the text as a strong draft rather than a transcript of record, and check anything you intend to quote.

Why is my transcript missing punctuation?

It is not on this page, and that was measured rather than assumed: a real run produces full stops, commas, question marks and sentence-initial capitals, with a timestamp at the start of every line. What is worth knowing is where those marks come from. They are produced by the speech model while it reads the words, not read off the audio, so a sentence boundary is the model's best reading of where the speaker stopped. If you have seen a transcript with no punctuation at all, look at what produced it rather than at the recording.

What happens if the file has no speech in it?

It says so in words instead of handing you an empty panel. That was measured here on four silent inputs — ten seconds of digital silence, ten seconds of a steady tone, ten seconds of quiet room noise, and a video with no audio track at all — and all four came back with the same message, no output panel and not one word of text. It matters because a speech model asked to read silence tends to produce words that were never spoken, so this page checks for speech before it formats anything. A tone is not music, though: a real music bed at normal level passes the level test, and the first cue can then be a marker or a line nobody said.

Does the transcript include the silent parts of the video?

No — silence produces no cue. Measured on a 19.5-second clip whose speech stops at 6.5 seconds, the transcript holds one cue at 0:00 and then nothing at all for the remaining thirteen seconds, so the text has a gap exactly where the audio does. That keeps every line pinned to something that was actually said, and it stops a subtitle from sitting on screen after the speaker has finished.

Is there a YouTube transcript API I can call?

No, and it is not a missing feature — an API needs a server to run on, and this page deliberately has none. The transcription happens in your browser, on the file you supply, so there is no endpoint to call and nothing that could accept your audio. If you need transcripts programmatically, the Whisper models this page uses are open source and can be run on your own machine instead.

Is the transcript word-for-word, or is it tidied up?

Tidied up, and that was measured rather than assumed. On a clip that says "um" once and "uh" three times, the default model returned text with none of those four sounds in it, and a word that was said twice ("the the") came back once. It is a readable rendering of what was said, not a word-for-word record. For notes, subtitles or a summary that is the right behaviour; for an interview or a study that needs the hesitations in it, it is not, and it is worth knowing before you rely on the text.

Why did the filler words disappear from my transcript?

Because the model writes readable sentences rather than recording sound by sound, and it treats a hesitation the way a writer would: it drops it. Measured here, the same file run with the smallest model kept three of the four filler sounds that the default model removed, so how much survives depends on the model you pick. If the fillers matter, run the smallest model and compare the two texts. Nothing in the output flags a dropped filler, because a dropped filler is not an error.

Does it write numbers as digits or as words?

As digits, in both runs that were measured. The test clip says "March third, twenty twenty-six" and "one thousand two hundred fifty dollars"; the text came back as "March 3rd, 2026" and "$1250" from the default model, and "$1,250" from the smaller one. So a spoken amount is written the way someone writing it down would write it. Check dates and amounts yourself if you intend to quote them, because the digit version reads as more correct than what was actually said, which makes the change easy to miss.

What is the difference between open and closed captions — and which ones can I get text out of?

Open captions are burned into the picture, so they are pixels: you can see them, and you cannot select, copy or export them, and a screenshot of them is a picture of words rather than words. Closed captions are a separate track — text that travels alongside the video — which is why a caption panel can offer you the text at all. This page works from neither: it reads the audio of the file you supply, so a video with open captions, closed captions or no captions is treated exactly the same way. The distinction still matters for a video you did not make, because if the words exist only as pixels, nothing can hand you a clean text file without reading the frames.

What happens to the transcript when the audio has background noise?

The text degrades, and the first things to go wrong are proper nouns, technical terms and numbers. That was measured here: a clean sentence naming "Dr. Margaret Chen from Stanford University" with a budget of "$47,000" for the "quantum computing laboratory renovation" came back perfect on the smallest model — every name and term intact. The same sentence with white noise mixed in at 35% came back as "Dr. Marsha's 10 from San Francisco University" with "quantum computing laboratory renovation" turned into "quarantine, including loud before we go to the base of this." Four out of four proper nouns and four out of four technical terms were wrong, and the date was lost. Heavier noise at 60% tripped the speech check entirely, so no text was produced at all.

Does switching to a larger model help with hard-to-hear audio?

Yes, and it was measured rather than assumed. The same noisy file that produced "Dr. Marsha's 10 from San Francisco University" on whisper-tiny.en was run again on whisper-base. The larger model recovered "Margaret" (though "Chen" came back as "Ten"), restored "Stanford University" correctly, and brought back "computing laboratory renovations" with only the word "quantum" dropped. Three of four proper nouns and three of four technical terms were now right, where the smaller model had zero of each. If the recording is less than clean and the text matters, switch to whisper-base before you conclude the tool failed.

Does a 4K video or a vertical Short transcribe any differently?

No, and it was measured rather than assumed. The picture is never decoded, so resolution and aspect ratio cannot change the text. One recording was wrapped in four containers and run four times: a 720×1280 vertical file of the shape a Shorts download arrives in, a 1920×1080 file, a 3840×2160 file, and the audio on its own. All four returned the same twenty-four words in the same order with the same two cues, character for character identical. Each video file also had a word painted into the picture that was never spoken, and none of those words appeared in any transcript. Once the model was cached, the 4K run was no slower than the 1080p run. What does change the outcome is whether the file contains speech, and how much memory your device has for a very long recording.

Can I transcribe a whole playlist at once?

No — one file is on the page at a time. That was measured too: pick a second file and the result from the first is cleared from the screen. There is no queue and no batch mode, because there is no server holding the work; each transcription runs in your own browser and ends when it ends, and nothing is remembered about the files you have already done. A playlist is therefore worked through one video at a time — transcribe, export, pick the next. The upside of that limit is the same property that keeps the whole thing off a server: nothing about your files is stored anywhere between runs.

Does the transcript say who was speaking?

No, and it is worth knowing that before you rely on a quote. The Whisper models this page runs do not separate speakers, so the output carries no speaker labels and nothing marks the point where the voice changes — a question and its answer arrive as two consecutive lines of the same undivided text. What you get instead is a timestamp on every line, which is the tool for the job: find the second a sentence came from, play that second back, and attribute it yourself. There is no confidence mark anywhere in the output either, so a line spoken by someone else looks exactly like a line spoken by you.

Which model should I pick if the video is not in English?

Pick one of the multilingual models: whisper-base, which is the default, or whisper-tiny if the device is short of memory. That is a measured answer, not a guess. A Spanish clip, a German clip and a Japanese clip were each run on whisper-base, and each came back in the language it was spoken in, with nothing translated into English. That holds for a recording in one language. A sentence in another language inside an otherwise English recording is the case where it breaks: measured on 2026-10-23, a Spanish sentence in the middle of an English recording came back written in English, and the podcast page has the five fixtures. The same Spanish clip was then run on whisper-tiny.en, the English-only model: it did not translate it, and it did not fail on it either — it produced 402 words of a single repeated phrase, and the run still ended with the page's ordinary Done message and no warning. whisper-tiny.en is the English-only model, and it is only the right choice for English audio.

Can I get the transcript in English from a video in another language?

No — this page transcribes, it does not translate. Measured: a Spanish clip came back in Spanish, a German clip in German, and a Japanese clip in Japanese, still written in Japanese characters rather than romanised. The multilingual models work out which language is being spoken and write that language down. A sentence in another language inside an otherwise English recording is the exception, measured on 2026-10-23: it came back in English, and the podcast page has the fixtures. Getting the language right is not the same as getting every word right — the Japanese clip came back in Japanese with two words wrong. If you need English text from a video in another language, export the transcript and translate the file: TXT, SRT and VTT are all plain text, so anything that takes text will take them.

Why does the page say the last run did not finish?

Because a run writes a mark before it starts and clears it when it ends, and a tab that is killed outright — the browser reclaiming memory, the phone sleeping, the app being closed — runs no code at all on the way out, so the mark is left behind. The next visit reports it once and then clears it, so the same run is not reported twice. It is an explanation rather than a recovered result: neither the audio nor the transcript is kept between visits, so what you get back is the reason, and the chance to pick a smaller model or a shorter clip before starting again.

Can it tell a run that is still going from one that was killed?

Yes, and that is what the check is for. A run holds a browser lock for as long as it lives, and the lock dies with the tab, so a second tab opened beside a run that is still going finds the lock taken and says nothing, rather than blaming memory for a job you can watch progressing in the other tab. Where the browser has no such lock, the mark carries a heartbeat instead, and only a mark that has stopped beating is reported — the notice is deferred in that case, not lost. Measured on this page: with a run held open in one tab, a second tab said nothing and left the mark untouched; once the first tab was killed, the next visit reported it and cleared the mark.

Which file types can I upload?

Anything your browser can decode, which in practice covers MP4, MOV, WEBM, MP3, WAV, M4A, OGG, AAC and FLAC. That list was checked here rather than copied from a spec sheet: one recording was encoded into all nine containers and run through this page, and every one returned the same eighteen words — the container decides whether the file opens, never what the text says. Containers outside the list work whenever your browser can read them; .opus, .mkv, .3gp and .m4v all decoded in the same test, even though they are not named above.

What happens if my file's format is one the browser cannot read?

You get the reason, not an empty panel. This page never applies a format filter of its own, so a file your browser cannot decode fails the same way it would fail anywhere else — and the message names both things that were tried (the audio decoder and the media reader) and tells you what to do next: save the clip as an audio file, or try another video, and drop it in again. In the same nine-container test, .aiff and .avi were the two that could not be read, and both came back with that message rather than silence. Nothing is retried silently and nothing is uploaded to look for help elsewhere.

How do you know my file is not being uploaded?

By measuring it rather than trusting the architecture. Two recordings of the same synthetic voice saying the same words were transcribed here — one 22 KB, the other 339 KB, fifteen times the size. The page sent the same number of bytes for both, and not one byte of either file appeared in any request; the server behind the test received nothing at all. That the larger file was genuinely processed is not in doubt, because its transcript came back fourteen times longer than the smaller one's. And because a probe that cannot see an upload would pass such a test by accident, the same run finished by posting 100 KB of the audio on purpose: the server saw it and the signature check fired. The claim is falsifiable, and it survived the test built to break it.

Does the model download again every time I use the page?

No. The browser caches the model after the first download, and that was measured here rather than assumed: a first run in a fresh browser made eleven requests under /models/ for the default model — the small manifest, five configuration files, and the two weight files split into five pieces; the two smaller models cost nine, and a second run in that same page made none. Closing the browser and opening the page again was measured too, and it is not quite the same thing: only the small manifest file was asked for, and that one request does leave the machine — the page fetches the manifest again from this site over the network, and no model weights move. The transcript came back identical either way. It is why the first run on a device is slow and later runs are not — the tens of megabytes move once. Clearing site data, or using a private window, starts the download over.

What is that one request the page keeps making?

It is a small file at /models/manifest.json — 721 bytes — that lists which speech models this site stores and how large each one is. The page fetches it before the model, because it is what tells the page that a model is served from this site at all, and whether that model's weight file is split into pieces. It is the only thing that goes back to the server after a reload: the weights stay in the browser's cache, and the manifest is re-checked.

Can I close the tab and come back to the page later without a connection?

No, and this is the one part of the offline story that is easy to get wrong. The transcription needs no network once the model is cached, but the page does. Open this page again with the network off and it fails before the tool loads — measured twice, once after a long session and once immediately after a fresh online load — because the page is not served from the browser's cache. So the offline window is the tab you already have open; closing it ends that window, and you need a connection once more to bring the page back. The model is the part that survives: it stays in the browser's cache across a reload and across closing the browser, which is why a run after a reload moves no weights: the only thing it asks for is the small manifest.

How do I check for myself that a run uses no network?

Open your browser's developer tools, switch to the Network tab, and start a transcription. On a first run you will see the model files arriving from this site's own address. Once the model is cached the only row that appears is the small manifest, and on a second run in the same page not even that — measured here with the network switched off, where the transcript came back byte-identical to an online run and not one request was attempted. An empty list only means something if the list can fill, so the same check was fired at four kinds of request with the network off and caught all four. You are not looking at a panel that is quietly failing to record.

Does it work in a browser other than Chrome?

Yes, and that was measured rather than assumed. The same clip was run through this page in two separate browser engines — Chromium and Firefox — and both returned a character-for-character identical transcript, with an identical SRT and VTT beside it. In both, every model file came from this site's own address and from nowhere else. With the model already cached, the Firefox run finished with the network switched off and attempted no requests at all, which is the result the Chromium run gave too. The behaviour around a run that was killed mid-way was the same on both. Two engines were driven, not every engine: Safari was not part of that test, so on Safari treat the browser itself as untested here rather than as a promise.

If I split a recording into parts, will the parts lose any words?

Not if you cut at a pause, and that is the whole difference — measured on this page. One 29-second recording of continuous speech was cut in two. When the cut landed in a real pause, the two halves came back as the same 94 words as the single run: nothing lost, nothing repeated. Cut at an arbitrary second inside speech instead, and the two words under the cut appeared in neither half — 92 words against 94. Two things to expect when you join the parts: each half's subtitles restart at 00:00:00,000, so the second half's times have to be shifted by the length of the first, and a part shorter than 15 seconds is not split internally at all.

After I close the page, what is left on my device?

The downloaded model, in the browser's own file cache — the Cache Storage API, which is a separate storage area from localStorage. Measured on this page: the default whisper-base leaves 79,677,901 bytes in a cache named transformers-cache, and the next run asks for nothing but that small manifest. Your audio is not kept at all, and a marker that records a run in progress deletes itself the moment the run ends. The only other thing that may be stored is your model choice, and only once you have changed it by hand or the page has stepped down a size. Clearing this site's data, or using a private window, makes the next run download the model again.

Privacy

Nothing you drop here leaves the browser — measured rather than asserted: two clips carrying the same words, one fifteen times the size of the other, sent the same number of bytes from this page, and not one of those bytes carried either file. Two analytics tools do report the visit: Cloudflare Web Analytics, which uses no cookies and does not fingerprint anyone, and Google Analytics, which writes _ga and _ga_KJ155PR9B7 into this browser, both kept for two years. There is no account either way. The privacy policy says exactly what each of them records. Close the tab and the file is gone.

Working with TikTok, Instagram and audio-only files too

Nothing on this page is specific to YouTube except the wording. The same engine handles the other short-video platforms on their own pages: the TikTok transcript generator for TikTok video transcription, and the Instagram transcript generator for Instagram Reels — same in-browser engine, same no-upload promise, same SRT and VTT export.

Audio with no video attached has a page too: the MP3 to text converter takes an MP3, a WAV or a voice memo directly and returns the same timestamped text, SRT and VTT.