Animated GIFs store a delay for each frame in hundredths of a second. A requested video frame rate may therefore produce different timing after GIF conversion.
Why the frame rate can change
For equal frame delays, delay in centiseconds = 100 ÷ frames per second. If an encoder rounds every delay to the same integer, 24 fps becomes 4 centiseconds per frame (25 fps); 30 fps becomes 3 centiseconds (about 33.33 fps); 60 fps becomes 2 centiseconds (50 fps).
These are examples of uniform rounding, not guaranteed Picsart output rates. Encoders can vary delays between frames to approximate an average rate. Players may also impose minimum delays.
Choose and check your output
- For uniform delays, 10, 20 and 25 fps correspond to 10, 5 and 4 centiseconds per frame.
- Inspect the exported animation in its destination player. Compare total duration and motion, as well as reported frame rate.
- If precise video timing or audio is required, use a supported video output such as MP4 or WebM and verify the destination requirements.
- Reduce dimensions, duration or frame count if the GIF is too large. File size also depends on image content and encoding; it does not increase by a fixed multiplier.
Troubleshooting
A changed frame-rate label alone does not establish a conversion error. If playback is visibly too fast or slow, compare frame delays and total duration with the source. Share the requested conversion settings, output details and observed timing with support; remove API keys and private media from any public report.
See the GIF89a specification for the frame-delay definition.