Export a Pitch Reel Under a File-Size Limit Without Guessing at Quality

A file-size limit is not a quality setting. It's a budget, and most people react to it by reaching for the preset menu and turning everything down a notch at a time until something fits.

That works by accident. It's expensive by design. You can end up shipping a file that passes the size gate with eighty-five megabytes of unused room in it and small type that has already turned to mush — a file that satisfies the only number anyone checked and fails the thing the reel was for.

The better order is short: fix the actual limit, do one piece of arithmetic to turn it into a starting bitrate, choose settings the receiving route supports, check the hard part of the reel, then measure the whole file and look at it. The arithmetic gets you close enough to stop guessing. The measured file is what settles whether you're done.

Establish the limit and the material that cannot fail

Get three things before you touch a slider.

The limit, and what it's denominated in. "Under 100 MB" is not one fact, it's a small cluster of them. Is it 100 million bytes, or 100 times 1,048,576? Is the uploader counting bytes and displaying megabytes, or counting the same megabytes it displays? Is the limit hard, or is it a human saying "keep it small"? You can ask, and asking costs one email. If you can't ask, use the stricter reading — 100,000,000 bytes — and you'll never be wrong about the gate.

The exact duration. From the timeline, to the frame. "About ninety seconds" is fine for conversation and expensive for arithmetic. Turning a 90.0-second reel into a 92.4-second one moves your bitrate budget by about 2.6%, which is roughly the size of a whole audio track you didn't plan to spend.

The route. Email attachment, upload widget, a USB stick handed to someone, a laptop driving a meeting-room projector, a phone on a train. This determines which container and codec you can get away with, and it determines how much detail you can afford to lose before anyone notices. A file your uploader accepts is not evidence that the recipient's player will open it, and those are two separate checks.

Then write down what cannot fail. Three items is plenty. Something like: the 14-point legal line on the title card, the six-second lateral move over the textured surface, and the twenty-second passage where a single voice sits at low level with no music under it. These are the things you will inspect, because these are the things compression breaks first.

And keep the master untouched. Everything below produces a delivery derivative. If the derivative is wrong, you go back to the master and try again — you don't keep re-compressing the compromise.

The mistake that looks like arithmetic

Here's a small made-up reel to work with, because the numbers are easier to see than describe. The reel runs 90 seconds. The recipient said 100 MB. There's a title card with small legal text, a six-second fast lateral move, and that quiet voice passage. No file was encoded for this article; everything below is arithmetic and a plan.

The first instinct is a division. 100,000,000 bytes across 90 seconds is about 1,111,111 bytes per second. Type 1111 into a bitrate field labeled kbps, set the audio to 192 kbps, export.

What comes out is roughly a 14.7 MB file.

It fits. It fits by eighty-five megabytes. And the fine text on the title card, at about 1.1 Mbps for 1080p, is going to be a grey smear that the client leans in to read. Nothing about that export fails the size check. It fails the only check that mattered, and it does so quietly, because the number everyone was watching says everything is fine.

The error is a factor of eight. Bitrate is bits per second; file size is bytes. You have to cross the units before you divide:

8 × 100,000,000 bytes ÷ 90 seconds ≈ 8,888,889 bits per second

That's a total budget of about 8.9 Mbps for everything in the file — video, audio, and the container's own overhead. Roughly eight times what the broken arithmetic handed you.

There's a second units trap sitting inside the first one. If the limit is enforced in binary megabytes, 100 MB is 104,857,600 bytes, which is 4,857,600 bytes more room than the decimal reading — across 90 seconds, about 430 kbps of extra video budget. If it's enforced the other way, decimal reading, binary assumption, you're 4.6 MB over. Either way it's a bigger swing than your audio track. Ask which one they mean, or plan for the smaller.

Turn the limit into a starting bitrate

Take the strict reading and subtract in the right order. Fixed costs come off the top, because audio and container overhead don't shrink when you get nervous about video.

So the video target is 8,500 kbps. The predicted file is (8,500,000 + 192,000) × 90 ÷ 8, plus roughly 250,000 bytes of container — about 98.0 MB, leaving a couple of megabytes of margin against the gate.

Three things about that table matter more than the numbers in it.

The estimate is a starting point, not a result. Nothing here has been encoded. Your encoder will not land exactly on 8,500 kbps; it will land near it, and the whole point of the margin is that near is good enough. This is also why a preset name is not a size guarantee — "1080p web" describes a bundle of decisions someone else made for a reel that isn't yours.

Bitrate controls are not interchangeable. Adobe's Media Encoder export settings reference treats target bitrate, maximum bitrate and encoding mode as three separate controls, and describes bitrate generally as data per unit time. That reference tells you what the controls mean. It doesn't promise what your file will weigh. A target is an average the encoder aims at; a maximum caps peaks above it; neither is a receipt.

A quality-based mode doesn't take a size target at all. If your encoder offers a constant-quality setting — a CRF number, a quality slider — it's choosing the bitrate for you based on how hard the material is. That's often the better choice for a master. It's the wrong choice when you have a hard size gate, because you have no way to tell it what the gate is.

Duration is your strongest lever on this budget, and the relationship is embarrassingly simple: halve the duration, double the bitrate budget. Cutting that 90-second reel to 75 seconds — with the recipient's agreement — raises the video budget from about 8.5 Mbps to about 10.4 Mbps. Same limit, meaningfully better picture, one honest conversation.

If the limit is much tighter — 25 MB for the same 90 seconds — the total budget works out to about 2 Mbps of video. At that point you are choosing which information to lose. That's a conversation about presentation, not a slider you haven't found yet.

Choose settings the route supports

Pick the boring codec. H.264 in an MP4 container is the least adventurous option and usually the right one when you don't know what's at the other end, because support for it is the closest thing to universal in delivery files. More efficient codecs buy you real bitrate savings, and they also buy you playback failures on a machine you don't control. Efficiency is only worth something if the file opens.

You already know what your limit is worth in bits. Now spend it. Where the relevant controls live depends on the format you chose, which is why the same encoder presents a different panel for every container you pick — the reference we looked at above organizes its settings that way, by format, not by a single universal layout.

A few decisions worth making deliberately rather than by default:

• Frame rate. Fewer frames per second means fewer frames to encode, and the budget you save goes into the frames that remain. Dropping 30 to 24 is sometimes exactly right for a stylized reel and sometimes exactly wrong for smooth motion.
• Resolution. It is tempting to assume that a smaller frame costs less and therefore preserves more. That isn't a safe assumption for small type, where resolution loss and bitrate loss damage legibility in different ways. This is a comparison you should run on your own material, not a rule you should import.
• Audio. Moving 192 kbps down to 128 kbps frees about 0.7% of your video budget. It is not nothing, but it is not the lever you're looking for. Don't spend your afternoon here while the video target goes unexamined.
• Two-pass encoding. If your encoder offers a two-pass variable-bitrate mode, it exists to hit a target average more closely than a single pass. That's a good match for a hard size gate.

Test the hard passage before the whole reel

Now take your three cannot-fail items and cut a sample that contains all three: the fine legal line, the fast lateral move, the quiet voice. The sample has to be long enough to hold the longest of them — the quiet passage alone runs twenty seconds — so for this reel it comes to about thirty.

Export the sample at the settings you derived. Then watch it at the size the recipient will actually see it. Not zoomed to 200% on your editing monitor, which is not a viewing condition anyone will use, and not on your phone if the real destination is a meeting-room projector. If the small type survives at that size, it survives.

Change one consequential setting at a time and look at what it cost. Going from 8,500 to 6,000 kbps, what happened to the legal line? Was it the letterforms closing up, or the thin strokes breaking first? That tells you where your floor is, and it's a floor for this reel — not for the next one.

Then stop the sample test and do the more important thing: don't use it to predict the file size.

The sample answers a quality question. It cannot answer the size question, and asking it to is a trap. File size is a property of all 90 seconds, and you chose those 30 seconds on purpose because they're the hardest part of the reel. It is not a scaled model. Container overhead doesn't shrink proportionally with a shorter clip. Rate control across thirty seconds and across ninety don't behave the same way. Three times a thirty-second sample is a coincidence, not a measurement.

Measure the whole file

Export the complete reel and count the bytes.

Compare that count to the limit in the same units the limit uses. If the recipient said 100 MB and their uploader enforces bytes, 98,035,000 bytes passes and 104,500,000 doesn't, regardless of what either of you calls it.

Then do the four checks that a size number can't do for you:

1. The beginning, where title cards with small type usually live.
2. The end, where credits, URLs and contact details get squeezed into the last four seconds.
3. The difficult passage, at the intended viewing size, not at your desk zoom.
4. The sound, and specifically the quiet part. Compression artifacts love a low-level voice with no music covering them.

Then run the actual delivery route. Put the file through the real uploader and open it on the real machine, or hand it to one person who will open it the way the recipient will. A file that passes your export dialog and dies in a recipient's player is the failure mode nobody's size check catches.

If the file is over, or it's under and the important content is gone, you have two honest moves. One is to reallocate: change the video target, change the frame rate, change the codec, renegotiate the duration. The other is to change the presentation with the recipient's agreement — split the reel into two files, cut a section, drop the fine print to a size the budget can carry. What you don't do is quietly delete the hard passage or drop the legal line so the number passes. That produces a file that fits and a reel that no longer says what it was built to say, and the person who asked for it will never know why it feels thin.

What you end up holding

Your finished answer is not a settings screenshot. It's two sentences and a number.

The number is the measured byte count from your actual export, in the units the gate uses. The two sentences are the compromise, named: the file measures 98.0 MB against a 100,000,000-byte limit; the legal line reads cleanly at presentation size and the fast lateral move softens in the background texture while the subject stays sharp; the quiet voice passage is clean.

Your version of that sentence has your numbers in it, because yours came from an encoder and mine didn't. If you can't write the second half — if you don't know what your export gave up — then you haven't finished the export. You've only finished guessing, and the file is the only thing that can tell you the difference.

Frequently asked questions

How do I turn a file-size limit into a starting bitrate?

Cross units first: multiply bytes by 8, then divide by exact duration. For 100,000,000 bytes over 90 seconds that is about 8,888,889 bits per second total. Subtract audio, container and muxing reserve, and rate-control slack to get a video target; in the worked example that lands near 8,500 kbps.

Why does dividing 100,000,000 by 90 and entering 1111 kbps give a bad file?

The limit is in bytes and bitrate is in bits, so the result is off by a factor of eight. The file may fit by a huge margin but the fine legal text can become a grey smear. The strict starting budget is about 8.9 Mbps for everything, not 1.1 Mbps.

Is a quality-based or CRF mode a good choice under a hard size gate?

Not for the gate. A constant-quality mode chooses bitrate based on how hard the material is, so you cannot tell it the size limit. It may be the better choice for a master, but a hard size limit needs a bitrate target or an equivalent size-directed workflow.

Can I test a short sample and multiply its size to predict the whole reel?

No. The sample answers a quality question, not a size question. File size is a property of the whole duration; container overhead and rate control do not scale proportionally. Export the complete reel and count the bytes.

What should the finished export contain?

A measured byte count in the same units the gate uses, plus a short statement of the compromise: what survived, what softened, and what was clean. Also run the real delivery route, because a file that passes export can still fail in a recipient's player. If you cannot say what the export gave up, you have not finished the export.

Further reading

• Send a Smaller Editable Pitch Reel: Trim the Media or Keep Complete Sources? — Read when the thing under the size cap has to stay editable: it distinguishes a viewing render from a revisable project and shows what trimmed media can support.
• What Must You Deliver With a Finished Film? — Read first, when the size limit arrives as a sentence rather than a specification: it shows how to turn an ambiguous delivery request into a specific written question.