Instagram Reels 300 MB file limit: bitrate budget by length

A Reel published through the Instagram API can be at most 300 MB, and its video bitrate at most 25 Mbps, so for any Reel longer than about 96 seconds the file size, not the bitrate cap, is what limits your quality. A 5-minute Reel has to average roughly 8 Mbps and a 15-minute one roughly 2.7 Mbps.

The limits come from Meta's IG User Media reference, read on 2026-10-02: video bitrate "VBR, 25Mbps maximum", audio bitrate 128 kbps, duration "15 mins maximum, 3 seconds minimum" and file size "300MB maximum". Sume's side is the video inspect and video trim docs. Sume does not let you set a bitrate, which matters below.

Where does the 300 MB limit start to matter?

Divide the file budget by the length. 300 MB is 2,400 megabits if you read MB as a million bytes (if Meta means MiB, every figure below is about 5% looser). At the 25 Mbps ceiling that budget lasts 96 seconds: 2,400 divided by 25. Under that length the bitrate cap is the only limit; over it, the average has to drop.

Audio uses a small slice of the same budget. Meta lists 128 kbps for audio, which is 0.128 Mbps, so subtract that from the video figure if you are close to the edge.

Is a 3-minute Reel at risk?

Rarely. A 1080x1920 clip at a typical social export rate sits well under 13 Mbps, so a 3-minute Reel fits with room. The risk is a long, high-bitrate master: a 10-minute screen recording at 12 Mbps would be about 900 MB, three times the cap, and a re-encode to roughly 4 Mbps is needed before it can be published.

Instagram's own Reels page says Reels can run up to 20 minutes in the app and that reels over 3 minutes will not be recommended to new audiences, so a very long Reel is also a reach decision, not only a file decision.

What can Sume check, and what can it not change?

Sume can read the size. A frames: false call to POST /v1/video-inspect is a probe only, and the docs state that probe and stills are unbilled. The inspect result's probe carries duration_seconds and size_bytes, so you can compute the average bitrate before you publish.

Sume cannot set a target bitrate. The video trim docs say the server compiles ffmpeg and refuses client fields such as codec and crf with ffmpeg_fields_rejected. What you can do is conform the output with output: { width, height, fps } (256 to 2160 pixels, fps 24, 25, 30 or 60) on an exact trim, and a smaller frame generally produces a smaller file. The docs do not promise a size, so measure the result with a second inspect call.

How do I compute the budget in code?

This plain Python function takes the probe values and says whether the file clears both limits. It makes no network call, so you can paste the two numbers from the inspect result.

def reel_fits(duration_seconds, size_bytes):
    mbps = size_bytes * 8 / duration_seconds / 1_000_000
    ok_size = size_bytes <= 300 * 1_000_000
    ok_rate = mbps <= 25
    return ok_size and ok_rate, round(mbps, 2)

print(reel_fits(180, 240_000_000))   # (True, 10.67)
print(reel_fits(600, 900_000_000))   # (False, 12.0)

def max_average_mbps(duration_seconds):
    return min(25, 300 * 8 / duration_seconds)

print(max_average_mbps(900))         # 2.666...

What should I do when a Reel is over the limit?

Pick the cheapest fix first. Cut it shorter: an exact trim with start and duration returns a new MP4 at $0.02 per job, and the source stays untouched. Split it in two parts if the story allows. Failing that, re-export at a lower bitrate in your editor, then publish and poll the container as in the status_code post.

Sume does not publish to Instagram. It prepares and checks the file; the Graph API call is yours.

Does the audio track change the budget?

Only slightly. Meta lists audio as AAC at 128 kbps with a 48 kHz maximum and one or two channels, so a 15-minute Reel spends about 14 MB on sound (0.128 Mbps for 900 seconds), which is under 5% of the 300 MB budget. Dropping the audio of a clip entirely would not rescue a file that is 3x over.

The bigger lever is the frame. Meta caps width at 1920 pixels and recommends 9:16, so a 1080x1920 master has nothing to gain from being larger. If your source is a 4K recording, a conform to a smaller frame on an exact trim is the first thing to try, and a second inspect call shows whether size_bytes moved enough.

Remember the order of operations: the cap is checked by Instagram when you create the container, not by Sume, so a file that passes your own arithmetic can still be refused for another reason. Treat the arithmetic as a filter that removes the obvious failures early.