The same budget, forty-six times apart
A megabyte limit sounds like it describes a length of video. It does not. It describes an amount of change. GIF stores frames as pictures rather than as motion, so the bill is written by how many pixels differ from one frame to the next. A terminal recording where a cursor blinks against flat color is nearly free. Handheld footage where grain and camera shake redraw the whole frame thirty times a second is ruinous.
The measured benchmarks on this site put a number on it. At 480 pixels wide and 15 fps, a screen capture costs about 10 KB per second of runtime. Camera-style footage at identical settings costs about 461 KB per second. That factor of forty-six is the most useful thing to know before you touch a single slider.
| Your source | Cost per second at 480px, 15 fps | What 2 MB buys |
|---|---|---|
| Screen capture, UI, flat color | ~10 KB/s | roughly 200 seconds |
| Camera footage, gradients, grain | ~461 KB/s | roughly 4 seconds |
So the first question is not which setting to change, it is which row you are in. On a dashboard recording, 2 MB is an enormous allowance and should be spent on width so the small type stays readable. On a person outdoors, it is four seconds, and everything after this is subtraction.
Divide first, then edit
Whoever set your limit probably means 2,000,000 bytes, though some systems mean 2,097,152. Assume the smaller and you never find out the hard way. Then do the only arithmetic that matters: multiply target seconds by target frame rate, and divide the budget by the result. That is your per frame allowance.
Three seconds at 12 fps is 36 frames, about 55 KB each, which is comfortable. Ten seconds at 20 fps is 200 frames and the allowance collapses to 10 KB per frame, which for anything photographic is fantasy. Running that division before you open the settings panel tells you whether you are tuning a GIF or negotiating with your own expectations, and where to aim: plenty of room means raise the width until the type is legible, none means cut the clip in half first.
The dials pay very differently depending on your row
Most size advice goes wrong by prescribing one recipe to both rows. The measurements say otherwise. Dropping the palette from 256 colors to 64 takes about 38 percent off camera footage and about 10 percent off a screen capture. Extra Compression at Medium takes about 42 percent off footage and about 10 percent off a capture. The lossy tools were built to eat photographic noise, and flat interface color has very little for them to eat.
Which gives two different orders of operations. For footage: trim hard, then width, then frame rate, then palette, then Extra Compression, reading the live size estimate at every stop. For a screen capture, trim and width still work, but reach for the palette and the lossy dial last and expect them to disappoint. Your real enemy there is runtime, because a two minute walkthrough is two minutes of frames no matter how flat they are.
Width deserves a warning in both rows. Pixels scale with area, so halving it removes about three quarters of them, which makes it the strongest lever and the only one a viewer sees directly. Judge the result at the size the destination actually displays, not at full zoom. The full ordering lives on the small file walkthrough.
When 2MB is the wrong hill
Sometimes the budget and the content do not fit, and grinding the palette to 16 colors to force it is how you ship something ugly. If the clip has to run ten seconds and look like real footage, GIF is losing an argument with 1980s physics. Flip Output Format to MP4 and everything you just built comes out as silent H.264 instead, with a bitrate dial that lets you name the budget outright rather than creep up on it. That switch appears in browsers carrying their own encoder: Chrome, Edge, and Safari, with Firefox varying. The GIF to MP4 page covers the trade.
Do not reach for APNG to solve a size problem. It carries full 24 bit color, which is why gradients stop banding, and it measured roughly five to eighteen times heavier than the equivalent GIF in our own tests. It is a quality format that happens to loop. And the size readout is an estimate, produced by encoding a sample of your real frames: reliable enough to steer by, but leave a few percent of headroom rather than landing on 1.99 MB and hoping.
Twelve guesses that cost nothing
Hitting an exact number is not one decision, it is a dozen small ones with a check after each. On a converter running on somebody else's server, every check is an upload, a queue, and a download, so people take two swings and settle. Here the encode happens in the tab on your own processor, and the loop is short enough to actually converge: change the trim, read the estimate, change the frame rate, read again, revert whatever cost more than it saved.
The same architecture means the clip never leaves the machine it was recorded on. That matters more than usual here, because files that arrive with a hard size limit are usually headed somewhere official: a ticket, a compliance portal, an email to a client. No account, no watermark on the export, and no copy in a bucket after you close the tab. Open the tool, do the division, and spend the budget deliberately.