How do I get an Instagram transcript that says who said what?

Not from this tool, and the reason is structural rather than a setting you have not found. A transcript here is a list of cues with three fields — a start, an end, and the words — and no fourth field for a voice, so a two-person Reel comes back as one column of text with no speaker column and no turn marks. The recognition call is made with four options — language, task, return_timestamps, chunk_length_s — and none of them asks who is speaking; the string “diariz” appears 0 times in the 147,189 bytes of the recognition library this page loads, and “speaker” 0 times in the 22,349 bytes of app.js. What you do get is a 12-character timecode on every line, which is enough to label turns by ear — and for the case most Reels fall into, one person talking to camera, a label would spend 40 bits on every line to carry 1 bit of information.

The rest of this page is the arithmetic behind those two sentences: what a cue actually stores, why one cue can hold two voices, what a label costs at 300 lines (1,500 bytes of tags on top of 4,500 characters of timestamps), what the three pages that outrank this one say about speaker separation across 20,385 characters of their Instagram copy — two of them say nothing — and the three routes that do work when you genuinely need to know who spoke.

What a cue actually stores

The segment list is built in toSegments(), and every object it pushes has exactly three keys: start, end and text. That is not a display choice. It is the shape the model’s output is mapped into, and every consumer downstream — the panel, the clipboard, the .txt, the .srt, the .vtt — reads those three fields and nothing else. Across the 22,349 bytes of app.js there is no fourth field and no branch that would fill one, because there is no source for it.

• Two numbers and a string, taken from two properties. The start and end come out of chunks[i].timestamp and the words out of chunks[i].text. Those are the only two properties of a returned chunk the file reads; a speaker would have to arrive as a third property, and the 22,349 bytes of app.js contain no read of one.
• Whitespace inside a cue is collapsed to single spaces. replace(/\s+/g, ' ') runs before the cue is stored, so any line structure the model returns inside a cue is flattened and a cue is always exactly one line. In a 600-second two-person recording, every turn break that falls inside a cue is therefore gone before it reaches the screen.
• A cue with no words is dropped, not kept as a pause. The push is guarded by if (text), so silence between two speakers leaves no marker at all — not an empty line, not a gap, 0 bytes. The only trace of it is the distance between one cue’s end and the next cue’s start, and the panel prints neither: a 300-line transcript carries 4,500 characters of timestamp prefix and not one of them marks silence.

Why one cue can hold two voices

Because the boundaries come from the audio windows, not from the voices. The call sets chunk_length_s: 30, and the library fills in stride_length_s as chunk_length_s / 6 — 5 seconds here — then jumps window - 2 * stride, which is 20 seconds. So a 600-second conversation is handed over in 30 windows, and the cue boundaries you see are spans the model placed inside those windows. Nothing in that loop compares the acoustics of one window with the next to ask whether the voice changed.

• A 43-second clip is 688,000 samples, 2,752,000 bytes and 2 windows. Two people trading five short lines inside those 43 seconds still produce two windows; a change of voice at 00:00:07 and another at 00:00:11 both fall inside the first one, where the only thing that can split them is a sentence break, which is a different event from a change of speaker.
• Ten minutes is 38,400,000 bytes and 30 windows. Assume a turn every 10 seconds — an assumption, not a measurement — and a 600-second two-person interview has 60 turn changes. Thirty windows cannot place 60 boundaries even if the code were looking for them, which it is not.
• The vocabulary is absent, not just the setting. In the 147,189 bytes of the recognition library’s pipeline module held on this machine, the string “diariz” appears 0 times; the 21 uses of “speaker” are all speaker_embeddings in the text-to-speech path, which is a voice you feed in, not a voice it recognises.

What a speaker label costs, and when it is worth paying

A tag is cheap on one line and expensive in bulk, and the arithmetic is exact because a tag is ASCII. [S1] is 5 characters, which is 40 bits; the choice between two speakers is 1 bit; so 39 of every 40 bits on that line are overhead. [Speaker 1] is 12 characters, 96 bits, for the same 1 bit of information. At 300 lines the short form adds 1,500 bytes and the long form 3,600 bytes to a .txt that would otherwise be unchanged.

• For a single speaker the label carries nothing at all. One voice is log2(1) = 0 bits, so a column that repeats the same value on every line is a constant, and a constant costs 1,500 bytes at 300 lines while telling you exactly what you already knew from watching the Reel.
• It also widens the prefix by a third. The panel’s prefix is 15 characters — a bracket, the 12-character stamp, a bracket and a space — and [S1] makes it 20, which is 33.3% more prefix on every line: 6,000 characters of prefix across 300 lines instead of 4,500.
• It is worth paying when the voices alternate inside a minute. A 600-second interview, a Live with a guest, a carousel whose slides are different people: in those, a turn every few seconds means the tag is doing work on every line. One person talking to camera for 60 seconds is the opposite case, and it is the case most Reels are.

What the three pages that outrank this one actually say

Across the four Instagram pages the three sites publish — 20,385 characters of body text, with the heading lists and the scraper’s own metadata stripped, because those are not sentences a reader sees — the word “speaker” appears 4 times and “diarization” 0 times. All four hits are on one site, and all four are navigation rather than explanation.

• One site puts it on a badge and leaves it there. speakapp.com’s Instagram page lists six claims above the URL field — “99% Accuracy”, “50+ Languages”, “Speaker Recognition”, “Instant Results”, “Private & Secure”, “GDPR Compliant” — and “Speaker Recognition” is the third of them, two words with no sentence attached. The page’s other use of the word is a footer link, “Speaker Labels in Transcription”, filed under a meetings tool rather than under Instagram, so the promise on the Reel page points at a different product.
• The second site says nothing, in 2,834 characters. getthescript.app’s Instagram transcript page contains 0 uses of “speaker” and 0 of “diarization”, and its step list describes a transcript as text you copy or export, never as a conversation between named people.
• The third site says nothing either, in 7,291 characters. wayin.ai’s Instagram transcript page contains 0 uses of either word. It does name the formats it exports — plain text and the two subtitle files — but a subtitle file has no speaker field in either format, so the export list cannot deliver one.
• 0 of the three shows a labelled line. Across 20,385 characters there is no example of a transcript with turns marked, no explanation of how a two-person Reel would be handled, and no mention of what happens when two people talk over each other. The question is answered by a badge on one page and by silence on the other two.

Three routes that do work

None of them is a checkbox, and the first is the one that fits a Reel. Label by ear against the timecodes: every line already starts with a 12-character stamp, so you read the time, listen to that second, and type a tag in front of the line. It is 1,500 bytes of extra text on a 300-line transcript and about as much work as reading it once.

• Split the file and run each speaker separately. A 600-second two-person recording cut into two 300-second halves is 19,200,000 bytes each, and each run starts by setting the stored result to null, so nothing carries over between files except the loaded model. That model is 79.7 MB and stays in memory once loaded, so the second file costs 0 download and 0 seconds of model time; what it costs is your having to cut the audio accurately.
• Use a tool that does diarization, and expect it to be a different tool. Speaker separation is a second model that clusters voice characteristics over time; this page loads one model, for transcription, and calls it with four options. Nothing in the 22,349 bytes of app.js can be switched on to add a second one.
• Do not expect the language picker or the timestamp box to help. The picker changes which language token the decoder starts from, and the timestamp box changes whether the panel prints a prefix; neither touches the question of who is speaking, and the call is identical in all four combinations.

Can this tool tell me who is speaking?

No. Each cue it stores has three fields — start, end and text — and there is no fourth field for a voice, so the panel, the clipboard, the .txt, the .srt and the .vtt all come out unlabelled. The string “diariz” appears 0 times in the 147,189 bytes of the recognition library this page loads, and “speaker” 0 times in app.js, so there is no hidden path that produces a label you have not seen.

Does the speech model know who is speaking?

It is called as a transcription model, not as a diarization model. The pipeline is invoked with four options — language, task, return_timestamps, chunk_length_s — and the output it is asked for is text with times attached, which is what chunks[i].timestamp and chunks[i].text are read for. Whether a different checkpoint could label voices is a separate question from whether this page asks it to, and this page does not.

How do I tell two people apart in a transcript, then?

Use the timecodes and your ears, or cut the audio first. Every line begins with a 12-character stamp in square brackets — 15 characters of prefix before the first word — so you can play the Reel, stop at a turn, and type [S1] or a name in front of the line. On a 300-line transcript that is 1,500 bytes of added text, and the copy button and the .txt both hand you exactly what is on screen, so the labels travel with the file.

Will a two-person Reel come back as one paragraph?

No, it comes back as one line per cue, which is a different problem. Internal whitespace is collapsed to single spaces before a cue is stored, so a cue is always one line and a turn change inside a cue is invisible; a 43-second clip is 688,000 samples, 2,752,000 bytes and 2 windows, so a fast exchange can end up as two lines holding five turns. What you never get is a blank line or a marker where the speaker changed.

Does adding speaker names break the .srt or the .vtt?

No. A label goes into the text line of the cue, and the timing line is untouched: it stays a fixed 29 characters, which is why the scaffolding of 100 cues is the same 3,492 bytes whether or not the lines start with a name. What the label does change is the file size — 5 bytes per cue for [S1] , so 1,500 bytes across 300 cues — and the .vtt escapes nothing extra, because a colon and a digit are not characters WebVTT treats specially.

Is there a free way to separate the speakers?

Only the manual one, and it is genuinely cheap for a Reel. The transcript arrives with a start time on every line, so labelling is reading and typing rather than listening again from the beginning; at 300 lines it adds 1,500 bytes and about the length of one pass through the text. A 600-second recording is the point where that stops being pleasant, and where a tool built for diarization starts being the better answer.

Last checked: 24 October 2026. The source counts were read from the deployed files on this machine: app.js is 22,349 bytes with “speaker” 0 times and “diariz” 0 times, and the recognition library’s pipeline module held here is 147,189 bytes in which “diariz” appears 0 times and all 21 uses of “speaker” are speaker_embeddings in the text-to-speech path. The window arithmetic is read from the library source, where stride_length_s defaults to chunk_length_s / 6 and the jump is window - 2 * stride: 30, 5 and 20 seconds. The byte figures are arithmetic on RATE = 16000 in app.js and a 32-bit decoded sample — 16,000 × 1 × 4 = 64,000 bytes a second, so 43 seconds is 2,752,000 bytes, 300 seconds is 19,200,000 and 600 seconds is 38,400,000 — printed and re-checked on this machine before they were written down. The tag costs (5 and 12 characters, 40 and 96 bits, 1,500 and 3,600 bytes at 300 lines) and the prefix growth of 33.3% are the same kind of arithmetic. The 43-second clip figures — 688,000 samples, 54 words, 18 to 42 seconds across a dozen runs — are this tool’s own records from an ordinary browser tab on a two-core, 4.2 GB machine. The competitor counts are over 20,385 characters of body text in four files held in this site’s benchmark directory, measured after the heading lists were stripped; the badge text from speakapp.com is reproduced exactly as it appears there. The claim that a turn change and a cue boundary are unrelated events is an inference from the window arithmetic and from the absence of any voice comparison in the source, not a measurement of a boundary-crossing sentence.

If what you need is where a line sits rather than who said it, the timestamps page covers the 12 characters and why none of them is clickable. What to do with a transcript sets out the four outputs and what each costs in bytes, and Instagram’s own captions are the other kind of on-screen text, which carries no speaker either. When the recording is long enough that labelling by hand stops being reasonable, the Live replay page works out how many 30-second windows an hour of audio becomes, and the carousel page covers the case where each slide is a different person talking into the same phone.