Instagram Transcript for Accessibility: Captioning Your Own Reels

What you need before a Reel can be captioned

The words are the easy half and the timings are the hard half, and almost every tool in this category quietly swaps one for the other. Before any of that, three practical things decide whether you can caption at all.

• The Reel has to become a file on your own device. Instagram's Save button keeps it inside the app; it does not hand you a media file. A screen recording, a downloader, or the original export if the Reel is yours all produce one.
• That file has to be audio or video in one of nine containers: MP3, WAV, M4A, AAC, OGG, FLAC, MP4, MOV, WEBM. Anything else comes back HTTP 400 with that list printed in the error text, so the failure is at least self-explaining.
• Size comes before quality. On earlier runs on this site the upload ceiling sat between 3.18 MB and 3.35 MB, and a 30-second 1080p screen recording is roughly 24 MB, which is several times over. Pulling the audio track out first is the difference between a two-second upload and a rejection.

What comes back, measured on four reel lengths

We cut one piece of speech into reel-shaped clips of 15, 30, 60 and 90 seconds at 16 kHz mono and 64 kbps, and uploaded each of them twice to this site's own endpoint, which runs @cf/openai/whisper on Cloudflare Workers AI. All eight uploads returned HTTP 200 and success.

• 15 seconds, 121 KB: 235 characters, 42 words
• 30 seconds, 241 KB: 2,209 characters, 393 words
• 60 seconds, 481 KB: 2,373 characters, 422 words
• 90 seconds, 721 KB: 3,304 characters, 590 words
• SRT came out exactly 33 bytes larger than TXT at every length, and VTT 39 bytes larger. The wrapper costs almost nothing, because there is nothing inside it but text.
• Those four files are the same sentence looped, so read the counts as a shape rather than as a benchmark for natural speech.

The part that decides whether this works as accessibility: there are no timings

A file that reports zero seconds is not a caption track with small errors in it. It is text waiting for timings, and it will look broken in every player that reads it. If what you need is a finished caption track, the download is a starting point, not a deliverable.

Why we do not spread the text evenly instead

For a deaf or hard-of-hearing viewer that is worse than no captions at all, because the words appear before they are spoken and stay after they are gone, and the viewer has no way to tell that the file is lying.

• Sentence one really runs 0.50 to 3.56. Even division puts it at 0.00 to 10.00: half a second early, and on screen 6.95 seconds longer than it should be.
• Sentence two really runs 11.00 to 14.47. Even division puts it at 10.00 to 20.00: one second early, 6.53 seconds too long.
• Sentence three really runs 22.50 to 25.66. Even division puts it at 20.00 to 30.00: two and a half seconds early, 6.84 seconds too long.
• Every cue is wrong at both ends and the file looks completely normal, which is the whole objection. A fake timestamp is not a rough timestamp; it is a wrong one that nothing downstream can detect.

Getting real timings out of the audio

The timings are not lost - they are in the audio, and free software reads them back out. Running silence detection over that same 30-second clip found the six boundaries at 0.70, 3.30, 11.22, 14.34, 22.70 and 25.49 seconds, against true values of 0.50, 3.56, 11.00, 14.47, 22.50 and 25.66. The largest miss was 0.26 seconds and the smallest 0.13.

• The command: ffmpeg -i yourfile.mp3 -af silencedetect=noise=-40dB:d=0.3 -f null -
• It prints silence_start and silence_end pairs. The gaps between them are the stretches where someone is speaking.
• Drop those boundaries into any subtitle editor with the text you already downloaded, and you have captions with real timings.
• We do not do this automatically, because 0.26 seconds is good enough for a person to start from and not good enough for us to hand you as finished work.

What the text is worth on its own

One thing it will not give you is speaker labels. There is no diarization in the response - the six fields are success, transcript, language, engine, fileSize and fileName - so on a two-person Reel you get the words in order with no indication of who said which. For accessibility that matters, and the fix is manual: split the text yourself where the speaker changes.

• A caption draft you paste into the platform's own caption editor and let it align to the audio.
• A script for a subtitle editor, which is the route to a file with real timings.
• A translation source: translate the block, then time it in the target language.
• A check on auto-captions. If a Reel already has machine captions, a fresh transcript is how you find the words they got wrong.
• Notes for anyone who cannot listen at work, which is a larger group than captions alone serve.

Three error codes you will hit, and what each one means

• HTTP 400, unsupported format: the container is not one of the nine. The accepted list is printed in the error text.
• HTTP 400, non-empty file required: the file is zero bytes. This is what a screen recorder that never actually saved produces, and it is worth checking the file size before you upload.
• HTTP 422, the model returned no transcript: there is no audible speech in the clip. Silence, or a music-only stretch, lands here.

What we keep, and what we cannot do for you later

The file is POSTed to /api/transcribe over an encrypted connection, decoded and processed in memory by @cf/openai/whisper running on Cloudflare Workers AI, and the response is the text. There is no account, no file library, and nothing retained for training. The flip side is real: we cannot re-run a clip on your behalf or hand you a copy next month, so keep your own recording and your own text. If the Reel is about something sensitive, that is the arrangement working as intended - there is no archive to leak.