GIF to MP4

GIF to MP4 hands your animation to ffmpeg on the processing service, which decodes every frame and re-encodes it with x264 at the veryfast preset. The index is written at the front of the MP4, so a player can start before the whole file has arrived. The size difference comes from how the two formats store motion: a GIF holds every frame as its own 256-colour image with only modest compression between them, while H.264 codes most frames as the difference from the one before. A loop where much of the picture holds still is close to the ideal case for that, which is why a screen recording can drop by an order of magnitude and a grainy, fast-moving animation by much less. The result screen shows the before and after sizes measured from the actual files, so you are not left guessing which of those you got.

Quality is a constant-quality target rather than a size target — high, balanced and small reach the encoder as CRF 20, 26 and 32 — so you decide how much detail survives and the file size follows from that. There is no target-size option here. The three-second minimum is the other switch that changes the output: tick it and an animation shorter than three seconds has whole plays repeated until the total clears that mark, because several social platforms reject very short uploads. A one-second loop comes back as exactly three seconds and a 1.2-second one as 3.6, since it is complete repeats being added rather than a padded tail. Anything already three seconds or longer is passed through at its own length.

The frame-rate menu resamples the animation on the way through. Leave it on Match the GIF and every frame keeps the interval it already had; pick 15, 24 or 30 and ffmpeg resamples to that constant rate before the encoder sees anything. Downwards is the useful direction — a 30 fps screen capture written out at 15 drops half its frames and a good deal of its size with them. Upwards only repeats frames to fill the gaps: it costs a few kilobytes and buys no smoother motion, because the frames it would need were never in the GIF to begin with.

One property of the output is worth knowing, because it is not the one ffmpeg would choose. Left alone, the encoder matches a GIF's full-colour frames with 4:4:4 chroma and writes a file whose profile reads High 4:4:4 Predictive. No colour detail is discarded that way, which flatters the coloured text and hard edges a screen recording is full of, but 4:2:0 is the variant the wider world assumes: it is what phone hardware decoders and upload pipelines are built around, and a 4:4:4 file can be turned away where an ordinary MP4 would not be. So this tool pins 4:2:0 and the result comes out plain High profile. The cost is that colour is sampled at half resolution horizontally and vertically, which very fine coloured text or a hard colour edge can show; brightness detail is untouched.

Frame size crosses over intact but for one exception: 4:2:0 cannot describe an odd number of pixels, so an odd width or height is trimmed by one and a 499x281 GIF comes back 498x280, while an even-sized animation keeps its exact dimensions. Two other things do not survive at all. H.264 has no alpha channel, so a GIF with transparent areas is flattened — they arrive as a flat fill, white on the files this has been tried against, and nothing shows through them any more. And an MP4 carries no loop instruction of its own, so whatever page or app displays it decides whether it repeats.

Secure server processing. This operation requires temporary server processing.