-
Notifications
You must be signed in to change notification settings - Fork 0
Animated GIF and WebP Size Capacity
Short answer: a 1280×720 animation under about 90 frames — roughly 6–9 seconds at typical export speeds — will resize without anyone noticing. Some other common sizes:
| Animation size | Frames | Roughly this long |
|---|---|---|
| 1920×1080 (Full HD) | up to ~40 | ~3–4 sec |
| 1280×720 | up to ~90 | ~6–9 sec |
| 800×600 | up to ~175 | ~12–18 sec |
| 500×500 (thumbnail/social size) | up to ~340 | ~23–34 sec |
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 about 85 million.
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.
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.
Reduce the animation at the source and re-upload:
- Cut the frame count first. By far the most effective change; 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.
- Both together, for anything really large.