How do I get an Instagram transcript with timestamps?

Tick the box marked “With timestamps” — it is already ticked — and every line of the transcript begins with a timecode in square brackets, 15 characters before the first word. That is the screen view and the .txt file, and both carry a start time only. The two subtitle files carry more: an .srt and a .vtt each hold a start and an end for every cue, written in a fixed 12-character format, which is what a video editor or a web player reads. What none of the four does is make the timecode clickable. The transcript is a <pre> element filled with plain text, index.html contains 0 <video> elements, and the 22,349 bytes of app.js contain currentTime 0 times and seek 0 times — so there is no player on this page to jump into. A timestamp here is a locator you type into Instagram’s own scrubber, not a link.

What follows is the part that decides whether the timestamps are any use to you: which of the four outputs carries which field, why the panel can report more cues than the file contains, what the 12 characters are made of and what they cannot resolve, where a cue boundary comes from, and what the three pages that outrank this one say about timestamps in their own words — which, across 20,433 characters of their Instagram copy, is 12 uses of the word on one site and 1 on another.

What each of the four outputs actually carries

There are four things you can leave with: the panel on screen, the clipboard, a .txt file, and one of two subtitle files. Three of them are generated from the same array of segments, so the words never disagree; what differs is which timestamps survive the trip. The screen and the .txt keep the start of each cue and throw the end away. The subtitle files keep both, because a subtitle without an end time is not a subtitle.

• On screen: start time only, 15 characters of prefix. Each line is built as a bracket, the 12-character stamp, a closing bracket and a space, then the text — 15 characters before the first word on every line. Ticking or unticking the box after a run re-renders the panel from the segments already in memory, so it costs 0 seconds of model time and does not re-read the file.
• .txt and Copy text: whatever is on screen at the moment you click. Both call the same function, which returns the text content of the panel, so the file inherits the checkbox state at download time rather than the state at run time. On a 300-line transcript that is 4,500 characters of prefix either present or absent, and the file size changes by exactly that much.
• .srt: start and end, comma before the milliseconds. Each cue is an index from 1, a 29-character timing line such as 00:00:00,000 --> 00:00:30,000, then the text on one line. Across 100 cues the scaffolding alone — index digits, newlines and timing lines — comes to 3,492 bytes before a single word of transcript is counted.
• .vtt: the same times with a dot, plus an 8-byte header. The file opens with WEBVTT and a blank line, so the same 100 cues come to 3,500 bytes of scaffolding against the .srt’s 3,492 — exactly 8 more. The difference stops being 8 as soon as a cue contains an ampersand, an opening angle bracket or a closing one: WebVTT escapes all three and grows by 3 or 4 bytes per character, while the .srt escapes nothing and stays the same size.

Why nothing on the page is clickable

Because there is no video on the page to click through to. The tool reads the audio track, resamples it to 16,000 samples a second, and never draws a frame: index.html has 0 <video> elements and the panel that holds the transcript is a <pre> whose content is set as text. A timecode printed inside a <pre> is characters, not a control, and clicking it selects a word the way clicking any other word in a paragraph does.

• The source has no seeking code in it at all. Across 22,349 bytes and 580 lines, app.js contains currentTime 0 times and seek 0 times; the only three elements it creates are an option, a textarea for the clipboard fallback, and an anchor used to start a download, and that anchor has a blob URL and a file name rather than a position in a video.
• Copy returns exactly what you see. The clipboard and the .txt both read the panel’s text content, which is why a copied line and a downloaded line are identical, and why neither can carry an end time the screen never showed.
• The alternative is a two-second habit. A start time in the form 00:01:12 is what Instagram’s own scrubber accepts, so the workflow is: read the timecode in the panel, type the minutes and seconds into the app, and the frame is there. That is slower than a jump link and it works on any device, including the phone the Reel was shot on.

The 12 characters, and the rounding they were written around

A stamp is HH:MM:SS.mmm in the subtitle files and HH:MM:SS.mmm with a dot on screen, always 12 characters for anything shorter than 100 hours. The part worth knowing is the order of the arithmetic: the seconds are converted to whole milliseconds first, and the hours, minutes, seconds and milliseconds are cut out of that single integer afterwards. Rounding the fraction on its own is the obvious way to write it and it produces 00:00:12,1000 — 13 characters, a four-digit milliseconds field, and a cue that no subtitle parser will read.

• The milliseconds field cannot reach 1000. The remainder after dividing by 1000 is always 0 to 999, so the widest the field can get is three digits, and the length of a stamp never changes with the value — which is what lets a fixed-width prefix be counted on.
• One millisecond is 16 samples of audio. At 16,000 samples a second, the smallest step a stamp can express covers 16 samples, so the timecode is coarser than the audio it points at; two cues that differ by less than a millisecond print the same time, and the difference is lost in the text rather than in the transcription.
• Past 100 hours the width breaks, and it does not matter here. Hours are padded to 2 digits, so a day-long file prints 24:00:00,000 at its end; a Reel is seconds long and even a four-hour Live replay stays at 2 digits, so the case is out of reach of this tool rather than handled by it.

Why the .srt can hold fewer cues than the panel counts

The meta line under the title counts segments, and the subtitle files are built from a filtered copy of the same list. A cue whose end is not after its start is dropped before either file is written, because a WebVTT parser discards a cue that ends where it begins and a SubRip cue with two identical times is junk that some players hang on. So the number in the panel and the number of cues in the file are two different numbers, and the panel’s is the larger one whenever the model returns a span it could not close.

• An end that arrives missing is filled in, not invented. When the model returns a cue with no end, the end becomes the next cue’s start; for the very last cue it becomes the duration of the audio. A missing end therefore produces a real cue, and only a backwards end produces a cue that the filter later removes.
• If every cue is dropped you get a message, not an empty file. When no cue survives the filter the download stops and the page says so, rather than handing you a file with a header and nothing under it — which is the failure mode that looks like success until a player refuses it.
• The measured clip is small enough to check by hand. A 43-second recording is 688,000 samples and 2,752,000 bytes at 16 kHz mono, 2 windows of model work, and it returned 54 words in 18 to 42 seconds across a dozen runs on a two-core, 4.2 GB machine. That is the scale at which a timestamp is easy to verify: pick a line, type its timecode, and see whether the words you hear match.

Where a cue boundary comes from

Not from punctuation, and not from the length of a sentence. The audio is cut into 30-second windows with a 5-second stride, so consecutive windows overlap and each one advances 20 seconds; the model returns sentence-ish spans inside the window it was given, and those spans are what become cues. A sentence that crosses a window boundary is therefore split at the boundary, and the two halves arrive as two cues with two sets of times — which is a property of the chunking, not a mistake in the timestamps.

• Ten minutes is 38,400,000 bytes and 600 seconds of audio. That is the length at which a timestamp starts being genuinely useful rather than decorative: 600 seconds is 10 minutes of speech, which at the measured rate of 54 words in 43 seconds is around 753 words — an extrapolation from one clip, and one that assumes nobody pauses.
• Thirty minutes is 115,200,000 bytes, and the window count grows with it. 1,800 seconds of audio at 64,000 bytes a second, cut into 30-second windows that advance 20 seconds at a time, is more cues than the same file cut by hand would suggest — and every cue gets a timing line whether or not it contains a word.
• Each cue is forced onto one line. Runs of whitespace inside a cue are collapsed to single spaces before the cue is stored, because a blank line ends a cue early in both subtitle formats and a newline would break the timestamped view on screen. A long sentence therefore stays one long line in the file, and where it wraps is the player’s decision rather than the file’s.

What the three pages that outrank this one say about timestamps

The counts below are over the visible body text of the four Instagram transcript pages the three sites publish, fetched on 22 October 2026 and held in this site’s benchmark directory: 20,433 characters in total, with the heading lists and the scraper’s own metadata excluded, because those are not sentences a reader sees.

• One site carries the idea, and it carries it 11 times in 7,303 characters. wayin.ai’s Instagram page has a section headed “Searchable Timestamps” and says: “Every line of your generated Instagram transcript is timestamped and fully searchable. Click any timestamp to jump to the exact moment in the video—perfect for pulling quotes or clipping highlights.” That is the clearest statement of the promise in the corpus, and it is a promise about a player.
• Another site mentions timestamps once, in a FAQ answer about reuse. getthescript.app writes, in 2,846 characters of body text: “The plain-text and timestamped exports work for TikTok, Shorts, blogs, and newsletters — just respect the original creator’s rights.” Its step list does name the formats — “Export TXT, SRT, or VTT for subtitles, schedulers, and repurposing workflows” — but the two halves are never joined: the page never says which of those three exports carries the times, and it shows no example of one.
• The third site says nothing at all. speakapp.com’s two Instagram pages come to 10,284 characters between them and use the word 0 times; the single hit that a plain search finds on each page is in the benchmark file’s own metadata line, not in the copy. Its only promise about speed is about the free preview, which it describes as the first 2 minutes in a single click.
• 0 of the three shows a timecode. Across 20,433 characters there is no example of the format, 0 uses of the word “millisecond”, 0 of “comma” and 0 of “cue”, so nothing in the corpus answers the question a reader actually has: does the plain-text export carry the times, or only the subtitle files? The one page that offers “plain text (TXT / DOC / PDF)” and “timestamped formats (SRT / VTT)” as two separate groups implies the answer without ever stating it.

What a timestamp is good for once you have one

Four uses, in the order people tend to need them. None of them requires the timecode to be a link, and all four get better as the recording gets longer, because the value of a locator is proportional to the length of the thing it locates.

• Finding a quote again. A 10-minute Reel is 38,400,000 bytes of audio and roughly 753 words; scrolling for the sentence you half-remember is slower than reading its timecode and typing four digits into the app.
• Cutting subtitles. An .srt with a 29-character timing line per cue imports into editors and players that expect SubRip; the 3,492 bytes of scaffolding across 100 cues is the price of the format, and it is what makes the file self-describing.
• Publishing on the web. A .vtt is the format an HTML video element reads, which is the one place the 8-byte header and the escaping matter: an ampersand in the transcript has to arrive as an entity or the file is invalid, and the .srt deliberately does not do that because SubRip has no escapes of its own.
• Re-running one section instead of the whole file. With times on screen you can see which window a bad line came from, and a 30-second window is a clip you can cut and run again in the time it takes to re-read the page.

Can I click a timestamp to jump to that moment?

No. The transcript is plain text inside a <pre> element, index.html has 0 <video> elements, and app.js contains currentTime 0 times and seek 0 times across its 22,349 bytes, so there is no playback position for a click to change. Type the timecode into Instagram’s own scrubber instead; the panel gives you the start of the cue in HH:MM:SS.mmm, and the minutes and seconds are the part the app wants.

Does the .txt file have timestamps in it?

It has whatever is on screen when you press the button, because the .txt and Copy text both read the panel’s text content. With the box ticked each line carries a 15-character prefix, and a 300-line transcript is 4,500 characters longer than the same transcript with the box cleared; you can toggle the box after the run, at 0 seconds of model cost, and download again.

Are the timestamps word-level?

No, they are cue-level. The transcription call asks for timestamps with a flag set to true, not to the word setting the library also offers, so what comes back is one span per sentence-ish chunk and not a time for each word. The spans land inside 30-second windows that advance 20 seconds at a time, which is why a sentence crossing a boundary arrives as two cues with two sets of times.

Why does my .srt have fewer lines than the panel says?

Because the panel counts segments and the file is written from a filtered copy of them: a cue whose end is not after its start is dropped before either subtitle file is built, and the count in the meta line is taken before that filter. A missing end is filled from the next cue’s start rather than dropped, so the gap between the two numbers comes from backwards or zero-length spans, not from unclosed ones.

Which file should I give a video editor?

The .srt, because it is the format editors and most players expect and it needs no header. Its timing line is 29 characters with a comma before the milliseconds, and across 100 cues the whole scaffolding is 3,492 bytes. Take the .vtt when the destination is a web page: it is the same cues with a dot instead of a comma under an 8-byte header, and it escapes ampersands and angle brackets, which the .srt deliberately does not.

How precise are the times, really?

To the millisecond in print and to the window in origin. The stamp is 12 characters with a three-digit milliseconds field that cannot reach 1000, but the times come from spans the model placed inside a 30-second window, so the last three digits describe a rounding of the span rather than a measurement at that resolution. One millisecond is 16 samples of 16 kHz audio, which is the finest step the text can express.

Last checked: 23 October 2026. The character counts and byte figures are arithmetic on this site’s own source, re-checked by printing them on this machine before they were written down: the stamp format is 12 characters, the on-screen prefix is 15, the timing line is 29, and 100 cues of scaffolding come to 3,492 bytes in .srt against 3,500 in .vtt with its 8-byte header — built by running the same string construction the page uses, not by estimating. The audio figures derive from RATE = 16000 on line 236 of app.js and a decoded sample being 32 bits: 16,000 × 1 × 4 = 64,000 bytes a second, so 43 seconds is 2,752,000 bytes, 600 seconds is 38,400,000, and 1,800 seconds is 115,200,000. The source counts were read from the deployed files on this machine — app.js is 22,349 bytes and 580 lines, with currentTime, seek and any <a> string at 0 occurrences, and index.html has 0 <video> elements. The measured figures are this tool’s own records from an ordinary browser tab on a two-core, 4.2 GB machine: a 43-second clip of 688,000 samples returning 54 words in 18 to 42 seconds, and a valid 20-minute WAV of 76,800,000 bytes refused with an EncodingError. The claim that a cue cannot cross a window boundary is an inference from chunk_length_s: 30 on line 282 and the library’s 5-second stride, not a measurement of a boundary-crossing sentence. The competitor counts are over 20,433 characters of body text in four files held in this site’s benchmark directory, with heading lists and scraper metadata excluded; the sentences quoted from wayin.ai and getthescript.app are reproduced exactly as they appear there.

If what you actually need is the file rather than the times, what to do with an Instagram transcript covers the four outputs and what each costs in bytes. Instagram’s own captions are the other thing that puts text on a video, and that page is where the difference between a caption track and a timed transcript is set out. The Reel length limit explains why a long recording is cut into 30-second windows at all. When the transcript comes back empty rather than mistimed, the five failure modes separates a silent recording from a refused one, and transcribing a Live replay is where the window count for an hour of audio is worked out.