MiniPNG

Compress GIF Images Online

Compress GIF images, and see why the number varies so much

Just a minute...(/)

We are currently optimizing your images. Please wait a moment as we ensure the highest quality results for you.

Great, we have successfully compressed your images.

Images Optimized.

Compress GIF images, and see why the number varies so much

Put two GIFs through this page and you can get 40 percent off one and nothing at all off the other. That is not the tool being inconsistent, and it is worth understanding before you upload, because it is the most confusing thing about GIF. A GIF has no quality slider. There is nothing inside it to trade away for size the way there is in a JPEG. All a GIF compressor can do is remove repetition, so what comes back depends almost entirely on how much repetition your file arrived with.

Where the bytes in a GIF actually sit

In two places, and neither is the picture in the way a photographer would think about it. The first is the colour table: every GIF carries a palette of up to 256 colours, and an animated GIF is allowed to carry a separate palette for every single frame. The second is the frames. A GIF written carelessly stores each frame in full, repainting the entire canvas thirty times to move one small box across the screen.

So the work is to collapse those per-frame palettes into one shared table and stop re-storing what did not change. Neither step touches your colours. In the first test below, 29 separate frame palettes became one global table, the file lost 40 percent of its weight, and the four colours we sampled came back at exactly the values they went in with.

What we measured

We ran six files through this page and wrote down the byte counts of what came back.

FileOriginalReturnedChange
Screen-recording animation, 30 frames, 640 by 40041,699 bytes24,994-40.1%
Single frame with a transparent background1,990 bytes1,861-6.5%
Animation already tightly encoded, 24 frames334,312 bytes334,027-0.1%
Single frame already on one tight palette56,676 bytes56,6760%
Eight-frame animation loaded with comments, XMP, GPS and a colour profile15,850 bytes9,953-37.2%
A PNG dropped on this page703,830 bytes74,379-89.4%

The 40 percent file and the 0 percent file went through the same tool

The first row was a screen recording: thirty frames, most of the canvas identical from one to the next, and a separate palette on nearly every frame. There was a great deal of repetition to remove. The fifth row was a single still frame already sitting on one tight 256-colour palette, so there was nothing left to take, and it came back at exactly 56,676 bytes, the number it went in at.

This is the honest version of a promise most pages in these search results make loudly. If your GIF came out of a video converter, a screen recorder or an old export preset, expect a real saving. If it has already been through an optimiser, expect very little, and read a zero as the tool telling you the truth rather than shaving quality off to manufacture a percentage.

Your animation comes back as an animation

We checked that at the byte level rather than by watching it play. The compressed thirty-frame file still contained thirty frames, thirty timing blocks carrying the original 80 millisecond delay, and the loop extension that tells a browser to keep repeating. The canvas was still 640 by 400. Nothing was flattened into a still image and no frames were dropped to make the number look better.

Transparency survives, and so do your exact colours

A transparent GIF came back 6.5 percent smaller. We drew the result onto a canvas and read four pixels out of it: the corner was still fully transparent, the red was still 220, 40, 60, and the white was still pure white. The same check on the thirty-frame animation returned its header blue, its page grey, its row grey and its red box unchanged after a 40 percent reduction. Because the saving comes from removing repetition rather than from approximating colours, that is what you should expect.

If the file is still too big afterwards

A compressor can only remove what is repeated. It cannot decide that your animation is four seconds too long or that it did not need to be 800 pixels wide. Those choices are made before the file reaches this page, and they set the floor. The arithmetic is blunt: a GIF costs roughly its canvas area multiplied by its frame count, so halving the width and the height takes about three quarters off, and cutting the frame rate from thirty a second to twelve is usually invisible on the kind of clip people post. If a compressed GIF is still heavier than you want, those two dials will move it far further than any optimiser can.

Whatever text was hidden in the file leaves with it

A GIF can carry a surprising amount of writing you never see, and not all of it in one place. There are comment blocks, which on an animation can sit on every single frame. There is an XMP packet, which is where Photoshop and the rest of Adobe's tools park the camera make and model, the creator and copyright lines, and the GPS coordinates. There are plain-text extensions and colour profiles. None of it shows up when you look at the picture.

We built one file carrying all of it: ten comment blocks, a full XMP packet with latitude, longitude, altitude and a capture date, the camera make and model, the software that wrote it, a credit line and a copyright notice, a colour profile and a plain-text extension. Then we ran it through this page and read the result with a metadata tool. Every one of those was gone. The eight frames were still eight frames, and the animation still loops forever.

This happens on the same pass as the compression, so it costs you nothing and there is no second upload to make. It also explains a result you might otherwise find odd: a file can come back smaller even when the compressor found no repetition to remove, because the text that was riding along is no longer in it.

Other image types are welcome on this page

The uploader also accepts PNG, JPG, JPEG, WEBP, AVIF, SVG, TIFF, BMP and JFIF, and each file comes back in the format it arrived in. The PNG in the table above went in as a PNG and came out as a PNG, still 1400 by 900 when we read its header. Landing on the GIF page does not convert your other images into something else.

What you get

  • Every frame, every frame delay and the loop setting preserved
  • Transparency kept, with the same colour values you started with
  • Your original canvas size, unchanged
  • Per-frame palettes merged into one shared table, which is where most of the saving comes from
  • Comments, XMP, GPS coordinates, camera and creator details and colour profiles all stripped out on the same pass
  • Your picture data left alone when there is no repetition left to remove
  • No sign-up, no watermark, no email address

What's next?

For photographs rather than animations, Remove Photo Metadata clears EXIF and GPS without re-encoding the picture at all. If your GIF is a single still frame rather than an animation, Compress PNG is usually a better home for it. And for the same content in a format designed a good deal later than 1987, Compress WebP handles both stills and animation.

Frequently Asked Questions

Because there was not much repetition left in it. A GIF has no quality setting, so a compressor cannot trade sharpness for size the way a JPEG tool can. It can only merge the per-frame colour tables into one and stop re-storing parts of the canvas that never changed. A screen recording we tested lost 40.1 percent because it was full of repetition, going from 41,699 bytes to 24,994. A single frame already sitting on one tight palette lost nothing at all and came back at exactly 56,676 bytes, the number it went in at. Both files went through the same tool on the same day.

Yes, and we checked it in the bytes rather than by watching it. The compressed thirty-frame file still contained thirty frames, thirty timing blocks carrying the original 80 millisecond delay, and the loop extension that tells a browser to keep repeating. The canvas stayed 640 by 400. Nothing is flattened into a still image and no frames are dropped to make the saving look larger.

Not in anything we measured. The saving comes from removing repetition, not from approximating the picture. After a 40 percent reduction we drew the result onto a canvas and read the pixels back: the header blue, the page grey, the row grey and the red box were all identical to the originals. On a transparent GIF the corner was still fully transparent, the red was still 220, 40, 60 and the white was still pure white.

Yes, all of it, on the same pass as the compression. A GIF hides data in several places at once: comment blocks that can repeat on every frame, an XMP packet carrying the camera make and model, the creator and copyright lines and the GPS coordinates, plus plain-text extensions and colour profiles. We built one file loaded with all of that, ran it through this page, and read the result with a metadata tool. Ten comment blocks came back as zero. Latitude, longitude, altitude, capture date, camera model, creator, credit and copyright all came back empty, and the XMP packet was gone entirely. The eight frames were still eight frames and the animation still looped.

Change the two things a compressor is not allowed to change: the canvas size and the number of frames. A GIF costs roughly its area multiplied by its frame count, so halving the width and the height takes about three quarters off the file, and dropping from thirty frames a second to twelve is usually invisible on a short clip. Trimming a second off the end helps more than any optimiser will. If the GIF is really a single still image, it does not need to be a GIF at all.

Yes. The uploader accepts PNG, JPG, JPEG, WEBP, AVIF, SVG, TIFF, BMP and JFIF alongside GIF, and every file comes back in the format it arrived in. A PNG we dropped here went from 703,830 bytes to 74,379 and came back a PNG, still 1400 by 900 when we read its header. Nothing is converted into another format because of which page you happened to open.