How do you extract text from an Instagram video?

An Instagram video holds two kinds of text that have nothing to do with each other, and they need different tools. The words that are spoken live in the audio track; the words that are drawn into the picture — burned-in captions, text stickers, an on-screen username — live in the pixels. This tool reads the audio track and never opens a frame: across 22,349 bytes of its own source there are 0 occurrences of canvas, 0 of ImageData and 0 of any OCR call, so what comes back is what was said and never what was drawn. The second job is a different order of problem, and the arithmetic is the reason: one second of the 16 kHz mono audio this tool reads is 64,000 bytes, while one second of 1080×1920 picture at 30 frames a second is 248,832,000 bytes — 3,888 times as much, for a stream the model is never shown.

The three things people mean by “the text in an Instagram video”

The caption the poster typed. It is text attached to the post as metadata; it is not a pixel inside the video and not a word in the audio track. It is also outside this pipeline in both directions — the picker's accept list carries 12 entries, 2 wildcards and 10 named extensions, and 0 of the 12 accepts a link, a username or a post ID, so nothing about the post is reachable from here and nothing about the post comes back.
Text burned into the picture. Captions a creator drew on, text stickers, hashtags and usernames rendered into the frames. These are pixels and nothing else, which is why no speech model can reach them: reading them means running optical character recognition over decoded frames, and this tool contains 0 lines of that. canvas appears 0 times in its 22,349 bytes, pixel 0 times, OCR 0 times.
The words that were spoken. This is the only one of the three this tool handles, and it handles it without ever touching the picture: 1 call to decodeAudioData, 2 references to OfflineAudioContext, 0 to any video or canvas API. The result is a text transcript of what was said.
Instagram's own auto-captions, which are generated from the audio and drawn on the screen while the video plays. They are a viewing feature rather than a file, and they are not the same object as a transcript you can keep — which is why this tool writes out plain text rather than a screen recording, and why a minute of the audio behind it is 3,840,000 bytes before it becomes anything you can save.

Read the lanes left to right and the four kinds of text part company at three different points. The caption the poster typed never enters, because the picker’s accept list has 12 entries — 2 wildcards and 10 named extensions — and 0 of the 12 accepts a link, a username or a post ID. Text burned into the picture passes the picker and passes the decode, since a file carrying both tracks decodes its audio track, and then stops at the model: across the tool’s 22,349 bytes there are 0 occurrences of canvas, 0 of ImageData and 0 of OCR, so 0 frames are ever opened and the caption contributes 0 words. Only the spoken words reach the output, and they arrive as 960,000 samples and 3,840,000 bytes for a 60-second clip — 2 windows of 480,000 samples — whatever the file weighed on disk. The reason the third gate is where it is rather than a missing feature is the ratio behind it: a single 1080×1920 frame is 8,294,400 bytes, or 129.6 seconds of the audio this pipeline reads, and at 30 frames a second the picture stream runs at 248,832,000 bytes a second against the audio’s 64,000 — 3,888 times as much.

What this tool opens, and what it does not

The whole path is one decode and one resample. The chosen file is read into an ArrayBuffer, handed to AudioContext.decodeAudioData, and the result is rendered by an OfflineAudioContext to 1 channel at 16,000 samples per second before the model sees it. There is no second branch. If the file is an MP4 carrying a video track, that track is handed to the browser's audio decoder and the pictures are simply not part of the result — measured, a 60-second clip reaches the model as 960,000 samples, which is 3,840,000 bytes, whatever the file it came from weighed on disk.

The word frame appears twice in the source, and both are audio frames. They are Math.ceil(decoded.duration * RATE) and the first argument of OfflineAudioContext(1, frames, RATE). At RATE = 16,000 a 30-second window is 480,000 samples and a one-minute clip is 2 of those windows. Neither occurrence has anything to do with a picture.
The word video appears 4 times in the source, and all 4 are prose. They sit on lines 1, 213, 275 and 405 of app.js, and every one of them is a comment or a sentence shown to the visitor — the header comment, a decode error message, a progress line, a note about a music bed. 0 of the 4 is a call that opens a video track.
The picker accepts video files, which is not the same as reading them. Its accept list carries 12 entries with video/* and audio/* among them, so an MP4 is offered and chosen like any other file. What happens next is the audio decode, and the resample normalises the result: a minute of speech arrives at the model as 3,840,000 bytes whether it was handed over as an MP4, a MOV, a WebM or an MP3.

Both streams start in the same file and only one of them reaches an output. The left path is the whole of this tool: the audio track is decoded, resampled to 1 channel at 16,000 samples per second and cut into 30-second windows, so a one-minute clip arrives as 960,000 samples and 3,840,000 bytes. The right path is everything drawn into the frames — burned-in captions, text stickers, an on-screen username — and it stops at the barrier, because 0 frames are opened anywhere in the pipeline. The sizes on the two sides are why the barrier is where it is rather than a missing feature: a single 1080×1920 frame at 4 bytes a pixel is 8,294,400 bytes, which is 129.6 seconds of the audio on the left, and at 30 frames a second the right-hand stream runs at 248,832,000 bytes a second against the left-hand 64,000 — a ratio of 248,832,000 ÷ 64,000 = 3,888. The 1080-by-1920 resolution is the one assumption in these figures; the buffer sizes were printed by allocating them in Node on this machine, and the 64,000 is the Web Audio specification rather than a measurement, since a decoded sample is 32 bits and 16,000×1×4 = 64,000.

The arithmetic of the other job

Take one frame of a vertical video at 1080 by 1920 pixels, the size these clips are normally delivered at. That is 2,073,600 pixels, and at the 4 bytes per pixel an RGBA canvas uses it is 8,294,400 bytes for a single frame. Those two figures were printed by allocating exactly that buffer in Node on this machine rather than multiplied on paper. At 30 frames a second the picture stream is 62,208,000 pixels and 248,832,000 bytes per second.

One frame. 1080×1920 = 2,073,600 pixels, and 2,073,600×4 = 8,294,400 bytes at four bytes a pixel. The resolution is the one assumption in this section — it is the usual delivery size for a vertical clip — and the four bytes a pixel is the RGBA canvas convention. Everything after this point is arithmetic from those two inputs, printed rather than estimated.
One second of picture. 2,073,600×30 = 62,208,000 pixels, and 8,294,400×30 = 248,832,000 bytes. Against the 64,000 bytes a second of 16 kHz mono audio costs, the picture stream is 248,832,000 ÷ 64,000 = 3,888 times larger — and 62,208,000 ÷ 64,000 = 972, or 972 pixels for every single byte of audio the model is actually given.
One frame measured against the audio. 8,294,400 ÷ 64,000 = 129.6 seconds of the audio this tool reads. A single frame of picture therefore weighs as much as 129.6 seconds — more than two minutes — of the speech the model is handed, and 8,294,400 ÷ 3,840,000 = 2.16 times the whole 60-second clip that a minute of decoded audio makes.
What that means for reading on-screen text. Anyone extracting drawn text has to hold frames, and frames are the large side of this ratio by a factor of 3,888 every second. That is the whole reason this tool does not attempt it: not that the text is hard to see, but that the buffer such a model would have to be shown is 3,888 times the one this pipeline is built around.

Why the file that would give you the on-screen text is the file this tool refuses

There is a symmetry in the failure modes that is worth knowing before you try. Measured on this machine, a file with a picture and no audio track — a silent screen recording, which is exactly the kind of file someone chasing on-screen text might export — is rejected by the decoder, and rejected in about a second, because the decode runs before the 79.7 MB model download rather than after it.

The rejection is named rather than guessed. The browser reports a damaged file, a file with no audio track and a file too large for the tab with the same error object, and the page's message names all three instead of pretending to tell them apart. For a reader who wants the picture, this is the case that matters: the file that has the picture and nothing else is the one case where the picture is all there is, and it is the one case the pipeline stops at.
A file with both tracks is the normal case, and the picture is still dropped. A 60-second Reel with speech and a burned-in caption goes through as 2 of the model's 30-second windows, and the caption contributes 0 words because 0 frames are read. So if a caption sticker says something nobody says out loud, the transcript will not contain it — and that absence is the honest answer rather than a bug to report.

What the three best-known tools say about on-screen text

The three pages that outrank this one for instagram transcript were fetched again on 15 October 2026, and the counts below are over the copy held in this site's benchmark directory: 264,692 characters across their 33 files, or 347,262 characters once the stored autocomplete lists are included.

The distinction is named exactly once in all of that copy. The phrase on-screen or on screen occurs 5 times in 264,692 characters, and 4 of those 5 are on pages about something other than transcribing an Instagram video — a video-search feature, a Reels creation screen, a summariser. Exactly 1 sentence on an Instagram transcript page draws the line, and it is wayin.ai's FAQ answer: “WayinVideo processes the actual audio track of the video, not the on-screen text. Even if the creator didn't add native captions or text stickers, you will receive a highly accurate text output.” It is quoted here rather than paraphrased because it is the only sentence of its kind in the corpus.
None of them describes reading the on-screen text. The string OCR appears 0 times in 347,262 characters, burned 0 times and burn-in 0 times. The word sticker appears 5 times and text overlay 3 times, and all 8 of those are in posts about making a Reel rather than about reading one. So the position of the three tools is not that they forgot the second kind of text: one of them says in a single sentence that it does not read it, and the other two do not raise it at all.
The demand is on the other side of that line. Of the 349 entries in the autocomplete list fetched on 15 October 2026, 11 contain the word caption and 1 more contains subtitle. Entries 59 to 68 are ten consecutive rows, every one of them an extractor query — instagram caption extractor, instagram caption extractor from video, instagram caption text extractor among them. People are asking to take text out of a video, and the three pages holding 264,692 characters of copy answer the narrower question about the audio.

How to get the spoken words — the part this tool does

This route is the one the tool is built for, and every step below is arithmetic rather than advice: a minute of speech is 3,840,000 bytes of decoded audio no matter which container it arrived in.

Pick the file. Anything the browser can decode as audio. The picker's 12 entries cover video/* and audio/* plus 10 named extensions, so an MP4, a MOV, a WebM, an M4A or an MP3 all arrive the same way. A 60-second clip becomes 960,000 samples at 16 kHz, which is 3,840,000 bytes, and the picture is discarded on the way through.
Pick the language before you run it. Nothing detects it for you — the browser build of the recognition library has no detection step — and a wrong pick does not error, it produces confident nonsense. Measured, the same 43-second English clip returned 54 words with the picker on English and 404 words of repeated Spanish with it left on Spanish.
Expect 2 windows for a minute. The model is called with chunk_length_s: 30, so a one-minute clip is 2 windows of 480,000 samples each and a five-minute clip is 10. Measured on this two-core, 4.2 GB machine, a 43-second clip took between 18 and 42 seconds across a dozen runs, so the wait grows with the window count rather than with the file size.
Rename the download the moment it lands. All 3 exports are written as transcript.txt, transcript.srt and transcript.vtt whatever the input file was called, and the original name is stored on the result object where 0 export paths read it. A batch of clips becomes a stack of identically named files within a minute.

How to get the on-screen text — the part this tool does not do

This is a genuinely different pipeline, and the source is unambiguous about it: 0 occurrences of canvas, 0 of getImageData and 0 of any OCR call across the tool's 22,349 bytes. There is nothing to switch on and no hidden mode to find.

It means OCR over frames, and this tool has none of it. Reading drawn text is a picture problem: decode frames, find text regions, recognise characters. This pipeline decodes audio and resamples it, and 0 of its code paths ever produce a picture, so a caption drawn into the frames cannot appear in anything it outputs.
The memory arithmetic is why the two are not the same tool. A single 1080×1920 frame is 8,294,400 bytes, which is 129.6 seconds of the audio this tool reads, and at 30 frames a second the picture stream runs at 248,832,000 bytes a second — 3,888 times the audio rate. A tool built for speech is built around the small side of that ratio on purpose.
If the on-screen text is a caption the poster typed, it may exist as text elsewhere, but that is outside anything this page can verify, and it is not what this pipeline returns. What this pipeline returns is what the audio track says: a minute of speech costs 3,840,000 bytes before it becomes text, and text is what you get out.

Can this tool read text that is written on the screen?

No, and the reason is structural rather than a setting you have missed. Across the tool's 22,349 bytes of source there are 0 occurrences of canvas, 0 of ImageData, 0 of pixel and 0 of OCR; the only thing it ever decodes is the audio track, at 64,000 bytes for every second of it. Text drawn into the frames is therefore invisible here by construction, and no option in the interface changes that.

Does the video need captions before the spoken text can be extracted?

No — on-screen captions and the audio track are unrelated, and a clip with no captions at all transcribes exactly as well as one with them, because 0 frames are read either way. The only thing that decides whether you get words back is whether the audio track has speech in it: the model is handed 480,000 samples per 30-second window regardless of what is drawn on top of the picture.

Is the poster's caption part of the video file?

Not in the sense that matters here. The text a poster types is attached to the post as metadata rather than drawn into the frames or spoken into the track, so it is neither a pixel nor a word of audio and neither path on this page touches it. The picker's accept list has 12 entries and 0 of them takes a link or a username, so a post's own text is not reachable from this tool at all.

How can I tell which kind of text I ended up with?

By counting. Measured on a 43-second English clip, the model returned 54 words, which is 1.26 words per second of audio; a five-minute clip is 10 of the model's 30-second windows, and that rate extrapolates to about 377 words, an extrapolation from one measurement rather than a count of anything. If a five-minute clip comes back with 40 words, the run did not transcribe. And if what you wanted was a caption you can see on screen, no word count will help: 0 of the transcript's words were ever in the picture.

Last checked: 17 October 2026. The source counts on this page were read from the deployed files on this machine on that date: app.js is 22,349 bytes and style.css 11,749 bytes, the file picker's accept list has 12 entries made of 2 wildcards and 10 named extensions, the source contains 1 decodeAudioData call and 2 references to OfflineAudioContext, and 0 occurrences of canvas, ImageData, pixel and OCR. The buffer sizes were printed by Node on this machine rather than done on paper — a 60-second 16 kHz mono buffer is 960,000 samples and 3,840,000 bytes, a 30-second window is 480,000 samples, and a 1080×1920 RGBA frame is 8,294,400 bytes, which makes one frame 8,294,400 ÷ 3,840,000 = 2.16 minutes of that audio. The 1080-by-1920 resolution is the one assumption in the arithmetic and is the usual delivery size for a vertical clip; four bytes a pixel is the RGBA canvas convention; every product from them was printed and re-checked before it was written down. The 64,000 bytes a second comes from the Web Audio specification rather than a measurement, because a decoded sample is 32 bits and 16,000×1×4 = 64,000. The 79.7 MB and 43.6 MB model sizes, the refusal of a picture-only file, the 43-second clip's 18-to-42-second spread and the 54 words against 404 are this tool's own recorded measurements, taken in an ordinary browser tab on a two-core, 4.2 GB machine. The competitor counts are over 264,692 characters of their own copy held in this site's benchmark directory, or 347,262 characters once the stored autocomplete lists are included, and the one sentence quoted from wayin.ai is reproduced exactly as it appears on its page.

If the video you have is a Reel rather than a file on disk, the Reel length limit covers the ceiling that actually decides whether a long clip transcribes. If you want to know where the audio goes once you hand the file over, whether transcribing uploads the video answers that with the request list. If the run comes back empty rather than wrong, the five failure modes is the page to start from, and what to do with a transcript covers the four outputs and what each one costs in bytes. For the on-screen captions Instagram draws itself, how to get captions on a Reel is the page for that object rather than this one.