-
Notifications
You must be signed in to change notification settings - Fork 0
Animated GIF and WebP Size Capacity
Short answer: a 1280×720 GIF under about 30 frames — or the same animation as a WebP, under about 55 — will resize without anyone noticing. Some other common sizes:
| Animation size | Frames | Roughly this long |
|---|---|---|
| 1920×1080 (Full HD) | up to ~15 | ~1–1.5 sec |
| 1280×720 | up to ~30 | ~2–3 sec |
| 800×600 | up to ~60 | ~4–6 sec |
| 500×500 (thumbnail/social size) | up to ~120 | ~8–12 sec |
| Animation size | Frames | Roughly this long |
|---|---|---|
| 1920×1080 (Full HD) | up to ~25 | ~2–2.5 sec |
| 1280×720 | up to ~55 | ~4–5 sec |
| 800×600 | up to ~105 | ~7–10 sec |
| 500×500 (thumbnail/social size) | up to ~200 | ~13–20 sec |
These are approximations, not thresholds. They come from timing a handful of real animations, and the same file can vary by 25% or more between runs depending on how busy the service is and what else it's doing. Treat them as "comfortably fine" rather than "the exact point where it breaks" — an animation somewhat over these numbers will often still work, and one right at them won't suddenly fail.
What matters is frame count relative to dimensions — not the file size in MB. A 20 MB animation at 400×400 is easier to handle than a 5 MB one at 1920×1080. Multiply width × height × frames and aim to stay under roughly 30 million for GIF, or 50 million for WebP.
Scaling a long animation can take longer than a web request is allowed to take. When that happens the first browser request fails. However the scaling itself still finishes a moment later and the result is saved. Future requests for that size are served from the cached scaled version, so they succeed.
If an animation looks broken right after you upload it, reload the page.
A failed first load means the animation is close to the limit — trim it (below) if you'd rather it load cleanly the first time. If reloading never resolves it, the animation is past what the service can scale.
Every frame has to be decoded, resized, and re-encoded. The re-encoding is most of the work, and it has to happen one frame after another because each frame is stored as the difference from the one before it — so it can't be sped up by adding processing power. The service allows 30 seconds per image.
In practice: an 800×450 animation of 234 frames uses roughly 26 of those 30 seconds when scaled to 768×432 — and that's as a WebP. The identical animation as a GIF takes nearly twice as long, which is why the two tables above differ.
How much room you have also depends on the largest size your site displays the animation at. Most of the work goes into producing the scaled output, so an animation shown only as a small thumbnail has considerably more headroom than the same file displayed near full width. The figures above assume the demanding case.
Over the pixel limit. Width × height × frames beyond about 268 million. Sharp, the underlying library, refuses immediately — before doing any work — and the service serves the original unscaled. Detection is essentially free; the cost is re-sending a full-size file on each cache miss. This ceiling is a documented safety limit in the library, not something specific to this service.
Under the pixel limit but over the time budget. The resize starts and can't finish within 30 seconds. There's no equivalent safety net: the attempt is cut off, nothing is served in its place, and nothing is cached, so every subsequent request repeats the same 30-second attempt.
The second is by far the more expensive, and the one worth designing around. It's also the more likely of the two, since most animations run out of time well before they approach the pixel ceiling — which is why the frame counts at the top are the numbers to go by.
- Save it as WebP instead of GIF. The one fix that changes nothing about the animation itself — same frames, same dimensions — while roughly doubling what will resize successfully. It's also dramatically smaller: one test animation was 11 MB as WebP against 45 MB as a GIF. Try this before trimming anything.
- Cut the frame count. The most effective change if converting isn't enough; shortening the clip or lowering its frame rate helps more than anything else.
- Reduce the dimensions. Halving width and height cuts the work to a quarter.
- Any combination of the above, for anything really large.