What a GIF really contains
GIF dates from 1987 and each frame is limited to a palette of at most 256 colours, compression is lossless LZW, transparency is all or nothing per pixel, and the format can hold a sequence of frames with timing, which is why it became the default container for reaction clips, screen recordings and animated stickers. The files you have probably came from a messaging app, a Giphy search, a screen recorder, an old website, or a forum export. Photographic GIFs also exist from the era of early digital cameras and scanners, and they are the ones that benefit most from becoming JPG.
First frame only
The most important thing to know about this page: an animated GIF becomes a single JPG of its first frame. The browser's image decoder hands the worker one still image, and that is what gets encoded with mozjpeg compiled to WebAssembly. There is no frame picker, and the first frame is often a title card or a fade-in rather than the moment you want. If you need a specific frame, pause the animation in a viewer, take a screenshot, and trim it with Crop image. For a static GIF, none of this matters and the whole picture is converted.
Why the result may look worse than expected
Two features of GIF interact badly with JPG compression:
- Dithering. To fake more than 256 colours, GIF encoders scatter pixels of neighbouring shades in a fine pattern. To a JPG encoder that pattern is high-frequency noise, so it either costs a lot of bytes to preserve or gets smeared into blotches at lower quality. A GIF that looked acceptable can turn muddy as a JPG.
- Hard-edged transparency. JPG has no alpha channel. Transparent pixels in the GIF are dropped, and because they carry black colour values underneath, the transparent area typically becomes solid black. A sticker on a transparent background will get a black box around it.
Line art, text-heavy screenshots and clip-art GIFs also suffer JPG ringing on their crisp edges. For all of those, GIF to PNG is the better conversion: it keeps the palette and the transparency, loses nothing, and the file is usually small anyway because flat colour compresses well.
When JPG is the right target
Convert to JPG when the GIF is a photograph, when a form or app specifically demands JPG, or when you need the smallest possible still image and the source has no transparency. The quality slider offers 20 to 95 with 80 preselected. For a photographic GIF, 75 to 85 works well; the dithering noise means the file will be bigger than a JPG made from the original photo would have been, but still far smaller than the GIF. For a graphic that you must deliver as JPG, use 90 to limit the ringing around edges.
Typical outcomes, which vary a lot with content:
- An 800x600 animated clip of 2.4 MB yields a first-frame JPG of roughly 60 to 120 KB at quality 80.
- A 640x480 photographic GIF of 280 KB usually becomes 50 to 80 KB.
- A 400x400 flat logo GIF of 15 KB may come out at 20 to 35 KB and look worse, which is the signal to use PNG instead.
What else changes
The output is a progressive, 8-bit sRGB JPG with the same pixel dimensions as the GIF. Any comment block or application extension inside the GIF is discarded. The GIF's palette is expanded to full colour before encoding, so the JPG is not limited to 256 colours, though it cannot invent colours the GIF did not have. Everything happens in your browser; the GIF is never uploaded. Very large GIFs, for example long screen recordings, are decoded in full by the browser before the first frame is extracted, so on a phone a 100 MB recording can run out of memory and fail. If you need to make a whole animation smaller rather than extract a frame, this is not the tool; a video format would serve you far better. PNG vs JPG covers the lossy versus lossless trade-off.