Saving an Instagram Story: Four Files, Four Different Results

Six files, one recording

Same 15 seconds, same speaker, same day. The only difference is the container and the codec a saver might hand you.

• MP4, H.264 video and AAC audio - 3,977,555 bytes, HTTP 200 in 9.82 seconds, 5 characters and 3 words.
• MOV, H.264 and AAC - 3,976,484 bytes, HTTP 200 in 13.57 seconds, 32 characters and 7 words.
• MP4 with HEVC video and AAC audio - 5,022,545 bytes, HTTP 200 in 4.86 seconds, 32 characters and 7 words.
• WebM with VP9 video and Opus audio - 3,632,191 bytes, HTTP 200 in 4.83 seconds, 250 characters and 41 words.
• M4A, audio only - 242,854 bytes, HTTP 200 in 1.35 seconds, 32 characters and 7 words.
• MP4 with the audio track removed - 3,725,564 bytes, HTTP 500 after 2.94 seconds, no text.

It repeats, so it is not luck

We re-uploaded four of those files to check. The MP4 came back with the same 5 characters. The MOV came back with the same 32. The HEVC file came back with the same 32. The WebM came back with the same 250. Same bytes in, same text out, every time. That rules out a flaky connection. What it does not rule out is that this particular 15 seconds is awkward to work with. A 20-second recording in the same setup returned a clean 305 characters yesterday.

The cheap file was also the smallest

The M4A is the one to notice. It is 242,854 bytes against 3,977,555 for the MP4 carrying the same audio, and it came back in 1.35 seconds against 9.82. One command gets you there: ffmpeg -i story.mp4 -vn -c:a aac -b:a 128k story.m4a. Today it returned the same 32 characters as the MOV and the HEVC version, so it did not lose anything the big files had. It just stopped paying to upload pixels the model throws away.

What six files can and cannot tell you

We did not test every container a saver might hand you, and we only ran one recording. Six files, one clip, one day. The part that holds is narrow, so here it is plainly. The same audio came back at four different lengths depending on the file it arrived in. Every file also repeated its own result when we uploaded it again. Whether WebM wins on your story is not something six files can settle. Run two containers on your own clip and keep whichever one comes back fuller.

When there is no audio track at all

A saver will sometimes hand you a video with the sound dropped, and that fails differently from a wrong format. Our file with no audio track was 3,725,564 bytes and came back HTTP 500 after 2.94 seconds with a message about trying another supported file. The message points at the format, which is misleading, because MP4 is a supported format. Check with ffprobe -v error -select_streams a -show_entries stream=codec_name -of json yourfile.mp4 first. If that prints nothing, no amount of re-encoding will help, because there is nothing to read.

What to do when a saved story comes back short

Do not conclude the clip was silent. Ours returned 3 words in MP4 and 41 words in WebM from the same audio. Re-encode into a second container, upload that, and compare the two. If both are empty, then check for an audio track, because that is the failure that no re-encode fixes. And keep the audio-only version as your default upload: it is the smallest file, the fastest today, and the picture was never part of the answer.