Animated GIF Loses Animation? Conversion Keeps 1 Frame
Short answer: the moment you convert an animated GIF to a JPEG or a standard PNG, the animation is gone, and no tool can put it back, because those formats are built to hold exactly one image. We proved it directly: we encoded a three-frame GIF, 150 bytes, showing red then green then blue, and converted it. The output held a single still that sampled as pure red, the first frame, with the green and blue frames nowhere in the file. Worse, the still was not smaller: the animated GIF's payload was 200 base64 characters while the single-frame JPEG that came out measured 1,016, about five times larger. So conversion did not shrink anything, it just deleted two of your three frames. The fix is to stop thinking of JPEG and PNG as targets. If you need the motion to survive, keep it in an animated format such as GIF itself or animated WebP, which stores every frame and its timing. Our Image Converter works in your browser so you can test a conversion without uploading, and our guide to converting JPG to PNG or WebP covers the still-image side of format choice.
Why does my GIF become still after converting?
Because you asked a single-image format to hold a sequence, and it simply has nowhere to put the extra frames. A JPEG file is one compressed picture: a header, one stream of pixel data, and an end marker. There is no counter for frame number and no field for how long each frame should display. A standard PNG is the same story, one grid of pixels inside chunks. Neither has a place to write "wait 500 milliseconds, then show the next image."
An animated GIF is built the other way around. Its structure is a header, a color table, then a repeating stack of image descriptors, each carrying its own pixels and a graphic-control block holding the delay time, looping it as many times as needed. When a converter targets JPEG or PNG, it reads that stack, writes out one frame, and reaches the end of the output format. The remaining frames have nowhere to go, so they are dropped. This is not a bug in any particular tool. It is the difference between a format designed for one picture and a format designed for many.
What did our conversion test show?
We did not theorize about this, we built the file and converted it. On a Windows machine we hand-encoded a valid animated GIF from scratch: 16 by 16 pixels, three frames, each a solid color, red then green then blue, with a loop extension so it would repeat forever and a 500 millisecond delay per frame. We then parsed it back and pushed it through a browser conversion.
- The source was genuinely animated. Parsing the file structure found three separate image descriptors, confirming three real frames, at 16 by 16. The whole file was 150 bytes, a 200-character base64 payload.
- The converted still kept only frame one. We drew the GIF into a canvas and exported a JPEG. Sampling a pixel in the result returned pure red, the first frame's color. Green and blue, the second and third frames, appeared nowhere in the output.
- The still was larger, not smaller. The single-frame JPEG payload measured 1,016 base64 characters against the animated GIF's 200, roughly five times bigger. Its opening bytes were ff d8 ff, the JPEG signature. We also exported a PNG at 156 characters, which stayed tiny only because a flat single color is the easiest thing PNG can store.
That middle point is the part people miss. The assumption behind most conversions is "this will make my file smaller." For an animated GIF going to JPEG, the result can easily be several times larger while holding a fraction of the content. You lose two frames and gain bytes.
Why does the converted file get bigger?
Because the compression models are not comparable, and the JPEG path is doing fresh work the GIF never had to do. Our GIF was tiny for a specific reason: it used a four-color global palette and indexed every pixel to a single small number, so three frames of solid color compressed to almost nothing. That is the GIF format playing to its strength, an indexed palette that is brutally efficient for flat art and limited colors.
A JPEG has no palette. It treats the image as a full-color signal, runs it through a discrete cosine transform, and writes quantized frequency data plus its own headers and markers. For a flat solid-color frame that is enormous overhead: JPEG is designed to encode photographic detail, and handing it a single unvarying color means all that machinery produces a large block of coefficients to describe "everything is red." The 200-character GIF became a 1,016-character JPEG because the new format described the same single frame far less efficiently. The animation was the GIF's compact part, and it was the part that got thrown away.
Which formats actually keep animation?
Only formats that were designed with a frame stack and timing. If the motion matters, these are the real targets:
- Animated GIF. The safe default. Every browser, phone, and messaging app renders it animated, and it is what you already have. Keeping the original costs you nothing.
- Animated WebP. The best modern choice for a smaller file. It holds multiple frames with per-frame delay, supports transparency, and typically compresses better than the source GIF. If your goal was a lighter animated file, this is the conversion to make instead of going to JPEG.
- APNG. Animated PNG, used mainly in Apple contexts. It keeps animation inside a PNG container, but support is narrower than WebP, so use it when you know the receiver expects it.
The pattern is simple. Convert GIF to GIF, GIF to WebP, or GIF to APNG and the frames survive. Convert GIF to JPEG or standard PNG and you have deliberately chosen a single still. Our Image Converter lets you move between formats in the browser, so you can try animated WebP and check the result before committing, and the Image Compressor can trim a still image you have already flattened.
What if the app only accepts a JPEG or PNG?
Then the animation cannot travel, and the goal changes from preserving motion to choosing the best single frame. Converters keep the first frame by default, which is why our test output came out red. That is fine when the opening frame happens to be the clearest, but arbitrary when it is not. If your GIF tells a small story, the first frame may be a blank lead-in rather than the payoff.
When you are stuck with a still target, open the animation, find the frame that best represents it, and export that one on purpose. A deliberate single frame looks like a thumbnail. An arbitrary first frame can look like a mistake. Neither keeps the animation, but one of them at least looks intended, and you avoid the surprise of a file that is somehow larger than the thing you converted.
How do I make a smaller animated file without going still?
Trim the animation along the axes that cost bytes, and leave the frame structure intact. The levers that work are reducing the pixel dimensions, dropping the frame count to every second frame, shortening or lengthening delays so redundant frames merge, and limiting the color palette, which is where GIF gets most of its savings. Any of these keeps the file animated while cutting its size. Switching to JPEG or PNG removes the animation entirely, which defeats the purpose. If you want a genuinely smaller animated file, animated WebP is usually the single biggest win, because it applies more efficient compression to the same stack of frames.
What are the honest limits?
- We tested a synthetic GIF, not a downloaded one. Our file was 16 by 16 pixels, three solid-color frames, built by hand to isolate the behavior. Real GIFs from the web are larger, use many colors, and often use local palettes and disposal methods. The core finding, that JPEG and PNG keep one frame, holds for all of them, but your specific size ratio will differ from our five-times figure.
- Our JPEG was large because the source was tiny and flat. A 200-character GIF becoming a 1,016-character JPEG is a real measurement, but it reflects a solid-color frame, which JPEG handles poorly. On a detailed photo-like GIF, the size gap will be much smaller, sometimes with the JPEG coming out under the GIF. The direction of the finding, that flattening does not guarantee a smaller file, is the reliable part.
- We exported one still, not every possible frame. Our test confirmed the first frame was kept by sampling the canvas at time zero. We did not build tooling to scan every frame index across different converters, so a specific app might let you pick a different frame or might keep the last one. The default in browsers and most converters is the first.
- One browser engine. The conversion ran in headless Chrome on Windows. Other browsers and desktop apps use different encoders, so exact output sizes will vary. The single-frame behavior is a property of the target format, not of one engine, so it carries across tools.
- APNG support is uneven. We named APNG as an animated option, but it is not as universally rendered as GIF or animated WebP. If you need certainty, animated WebP or the original GIF is the safer bet.
What did we actually test?
We hand-encoded a valid GIF89a file on a Windows machine (2026-10-26): 16 by 16 pixels, a four-color global palette, a NETSCAPE loop extension, and three image descriptors each holding one solid-color frame, red, green, then blue, with a 500 millisecond delay per frame and a disposal method that cleared between frames. We wrote a small LZW encoder to produce the correct variable-code-size blocks, since the animation is only real if the byte stream is valid.
We then parsed the file back by walking its block structure, which found three image descriptors at 16 by 16, confirming the animation was genuine. The file was 150 bytes with a 200-character base64 payload. We loaded it into an Image element, drew it into a canvas, and exported both a JPEG at quality 0.9 and a PNG, reading the resulting payload sizes and the JPEG's opening bytes, which were ff d8 ff. Sampling a pixel in the canvas returned 255, 0, 0, pure red, proving the first frame was the one captured. The JPEG payload was 1,016 base64 characters and the PNG was 156.
What this test does not cover: it used a synthetic three-frame flat-color GIF rather than a downloaded animation, so the size comparison reflects JPEG's weakness on solid color rather than a typical photo. We confirmed the first frame was kept by a single pixel sample rather than by scanning every frame across multiple converters. The conversion ran in headless Chrome, so other tools may report different output sizes or allow choosing a different frame, though the first-frame default and the single-frame ceiling are properties of the target formats and hold broadly.
Quick FAQ
Why does my animated GIF become still after converting?
Because JPEG and PNG are single-image formats. They have one pixel grid and no field for a second frame or a delay timer. When a converter reads your animated GIF and writes a JPEG or PNG, it can only keep one moment. In our test, a three-frame GIF came out as a single still holding the first frame, with the other two frames gone.
Which frame does the converter keep?
Almost always the first frame. Our three-frame test GIF showed red, green, and blue in sequence. The converted still sampled as pure red, the first frame, and the green and blue frames were not present anywhere in the output. Some tools let you choose a different frame, but the default is the opening one.
Why is my converted still file bigger than the animated GIF?
Because the two are compressed very differently. Our three-frame GIF was 150 bytes and its base64 payload was 200 characters. The single-frame JPEG exported from it came to 1,016 base64 characters, about five times larger, because it is a fresh lossy encode with its own headers rather than a compact indexed frame. Losing the animation does not shrink the file; it often enlarges it.
Can any converter keep the animation in a JPEG or PNG?
No, and this is not a tool limitation. JPEG has no mechanism for multiple frames. PNG does have a less-supported animated variant called APNG, but a standard PNG saved from most converters is still a single image. If a tool promises to keep your animation inside a normal JPEG or PNG, the animation is being dropped.
What format should I convert to instead to stay animated?
Animated WebP is usually the best choice. It holds multiple frames with timing, supports transparency, and typically compresses smaller than the source GIF. APNG works too if the receiver is in the Apple ecosystem. Keeping the original GIF is always safe when you are unsure, since every browser and messaging app renders it animated.
How do I make a smaller animated file without going still?
Reduce the frame count, the dimensions, or the delay between frames rather than switching to a still format. Trimming to every other frame or shrinking the pixel size cuts bytes while the file stays animated. Converting to JPEG or PNG removes the animation entirely, which is the opposite of what you want.
Once you have the format you need, if the file is still heavier than you want for email or a portal, the Image Compressor brings a still image down without a second trip through a converter.