GIF Compressor

A GIF compressor that actually builds every quality level so you can pick one

This GIF compressor rewrites an animated GIF so the file gets smaller. It really builds all five compression levels, from lossless to maximum, and shows the resulting size of each as a bar. For example, the sample GIF made from a video (360 × 240, 32 frames, 1.70 MB) came out at 947 KB (−44.1%) at the Medium level, and the sample screen recording (400 KB) shrank to 87 KB (−78.4%) at the Lossless level alone, which does not change a single pixel.

Drag the divider on the stage to compare the original and the result at the same spot, then pause and step through frame by frame. The frame map below shows how many bytes each frame uses, so you can see which scenes are heavy. Pick a target size and the tool chooses the lightest level that fits; if even that is too big, it reduces the width until the file fits. Your GIF is never sent to a server: everything happens inside this browser.

When to use it

• Uploading somewhere with a size limit: according to GitHub Docs, images and GIFs attached to issues and pull request comments can be up to 10MB. If the screen recording you want to attach to an issue is larger, choose 10 MB as the target size. Chat apps, forums and email each have their own attachment limits, so check the page you are uploading to and aim a little below it.
• A blog or product page that loads slowly: animated GIFs made from video, such as a product in use, easily weigh several MB each, and a page with several of them opens slowly on a phone. The Light and Medium levels, which keep the picture almost as it was, often cut the size a lot on their own.
• Putting a screen recording into documentation: in a how-to recording most of the screen stands still and only a small part moves. The Lossless level rewrites only the parts that changed, so this kind of GIF gets much smaller with no loss of quality.
• Re-uploading a GIF you downloaded: GIFs that have been saved many times often store the full screen and a full palette in every frame. If the rebuilt file would be larger than the original, this tool simply gives you the original back, so checking costs you nothing.

How to use it

1. Drop your GIF on the workspace or press "Choose a GIF". You can also paste a copied GIF with Ctrl+V. One GIF, up to 50 MB, opens at a time.
2. As soon as the file opens, the Medium result is built, then the other four levels follow one by one and fill the compression bar with real sizes. Click any level to switch to that result.
3. If the place you are uploading to has a limit, choose a target size (1 to 15 MB, or your own). The lightest level that fits is selected, and if even Strong is too big, the width is reduced to fit.
4. If you want, change the width (original, 75%, 50% or custom) and the frames (all, or 1 of every 2 to 4). Open "Choose manually" to set the number of colors and the loss yourself.
5. Drag the divider on the stage to compare original and result. Press Pause, or click the frame map, to stop on a frame, then use the previous and next buttons or the arrow keys to step one frame at a time.
6. Press "Save GIF". The size is added to the end of the file name (for example funny-cat-947kb.gif).

How the five compression levels differ

Each step up allows more pixels to differ from the original. The sizes in the table below were measured by really shrinking the two samples with this tool. PSNR expresses the pixel difference between original and result in decibels: higher is closer to the original. In the animated GIF sample, "Medium" (around 35 dB) was hard to tell apart even at 2× zoom side by side, while "Strong" and "Maximum" (below 30 dB) added specks to the white background and roughened smooth surfaces such as the apples and pear. The same number can look different on another GIF, so treat it as a guide only.

• The video GIF did not shrink losslessly: in this sample the picture zooms in slowly and every pixel carries noise, so every pixel in every frame changes. With nothing unchanged to skip, the lossless result was not smaller than the original, so the tool hands you the original.
• For the screen recording, Lossless did most of the work: the original stores the whole screen in every frame, but only the numbers, the chart and the cursor actually change. Writing just those parts gave −78.4%, and the lossy levels save only a few KB more.
• From Strong on, colors are reduced: dropping to 128 or 64 colors puts steps (banding) into smooth areas such as sky or dark cloth, and the horizontal streaks of lossy LZW begin to show. That is why those bars are hatched, and why the target-size search never picks Maximum by itself.

Why a GIF can shrink without losing quality

The GIF specification (GIF89a) lets every frame's image descriptor state its left and top position on the screen and its width and height. A frame can therefore be a small rectangle rather than the whole screen. Each frame can also name one transparent color index, and according to the specification a pixel with that index leaves the screen unchanged, so the previous picture shows through. This tool uses both ideas to shrink the file without changing any pixel.

1. A rectangle around what changed: only the smallest rectangle that covers every pixel that differs from the previous frame is stored. In a screen recording where only the cursor moves, a frame becomes a rectangle the size of a thumbnail.
2. Unchanged pixels inside the rectangle become transparent: inside that rectangle, pixels that did not change are blanked out with the transparent index. Long runs of the same index compress very well with LZW. Scattered small changes can sometimes be smaller with the original colors, so for every frame two or three variants are compressed and the smallest is used.
3. Identical scenes just add time: a frame whose pixels are exactly the same as the previous one is not stored; its display time is added to the previous frame. The total playing time does not change.
4. Colors stay as they were: if all frames together use 255 colors or fewer, the original colors are written into one global palette. If there are more, each frame gets a palette holding only the colors used in its rectangle.

For a GIF whose transparent areas must become transparent again (a moving sticker on a transparent background, for example), the previous frame is switched to "restore to background" (disposal method 2) so the area is cleared before the next frame is drawn. The tool's own tests compared results with their originals pixel by pixel, frame by frame.

What lossy compression throws away

GIF compresses pixel indexes with LZW (Welch 1984). It collects the index sequences it has already seen in a dictionary and writes a single dictionary code whenever the same sequence comes again. Codes are at most 12 bits, so the dictionary holds up to 4,096 entries. Lossy LZW, when looking a sequence up, also accepts pixels whose color is only slightly different, so it can continue with a longer sequence. This is the same idea as the --lossy option of gifsicle: the longer the sequences, the fewer codes to write and the smaller the file.

• What changes: individual pixels become a slightly different, similar color. The difference is passed on to the next pixel so the average color is kept, but at high levels long horizontal streaks appear. It works well on photo-like video GIFs and has little effect on screen recordings made of flat colors.
• Leaving similar pixels alone: in a GIF made from video, even a still background changes a little in every frame because of noise. In the lossy levels, a pixel whose color is very close to what is already on screen is treated as unchanged and blanked with the transparent index. The comparison is always made against the current frame's original color, so differences do not pile up from frame to frame.
• Transparent areas stay transparent: transparent and opaque pixels are never swapped, even in the lossy levels. A sticker-style GIF keeps its outline.

What happens when you reduce the colors

A GIF palette has a power-of-two size (2, 4, 8 … 256) and holds at most 256 colors. Reducing to 128 or 64 colors lowers the number of bits needed for each pixel index, so the file shrinks. This tool picks colors with median cut (Heckbert 1982) from pixels sampled evenly across all frames, and makes every frame use the same global palette. Colors do not shift from frame to frame, so there is less flicker, and no frame needs its own palette.

• Flat-color artwork, icons and screen recordings use few colors, so even 64 colors changes little.
• Photos with smooth gradients, such as sky, skin and shadows, can show banding from 128 colors. Dithering is not used: it makes the dot pattern differ from frame to frame, which increases the number of changed pixels and makes the file bigger.
• In a long GIF with many scene changes, each scene has different colors, so a single global palette can make some scenes rougher. For these, stay at Medium or lower and reduce the width instead.

Reducing the width and the number of frames

When you reduce the width, the height shrinks by the same ratio, so the pixel count drops with the square of it: 75% width is 56% of the pixels, and 50% is 25%. Thinning the frames keeps 1 of every 2, and the time of each dropped scene is added to the frame that stays, so the total length is unchanged. The table below keeps the Medium level and changes only size and frames. The percentage in parentheses is the reduction compared with the original.

The video GIF shrank almost in proportion to the pixel count as the width and the frame count went down. The screen recording changes only a small area, so halving the width saves less than it does for the video. A screen recording with small text can become unreadable when you reduce the width, so try changing the level before the size.

GIF frame delays are counted in hundredths of a second. The source code of WebKit, the engine behind Safari, has a comment saying that, like Firefox, it shows frames with a delay of 0.01 second or less as 0.1 second. So when this tool merges frames, it counts a frame written as 0 or 0.01 second as 0.1 second before adding. Delays of frames that are not merged stay exactly as in the original.

How a target size is reached

1. With the current width and frame settings, the tool really builds the levels from Lossless up to Strong and picks the first one (the lightest) that comes in at or under the target. If the original is already within the target and Lossless does not make it smaller, the original is returned as is.
2. If even Strong is over the target, Strong is kept and the width is reduced. Because size is roughly proportional to the pixel count, the tool estimates the next width, builds it for real, measures, and repeats a few times to find the largest width that fits.
3. At the width it finds, all five levels are measured again, and the lightest level that fits is shown. The result area says what was changed, for example "To fit 2 MB, the width went from 360 to 300px".
4. If you click a level yourself, that level is used as it is, and if it is over the target you are told in red text.

Sizes are counted with 1 KB = 1,000 bytes and 1 MB = 1,000,000 bytes (SI prefixes). Displayed numbers are rounded up, so when it says "within 2 MB", the real byte count is also 2,000,000 or less. If the place you upload to counts in MiB (1,048,576 bytes), the same number leaves you a little extra room.

How to read the frame map

The frame map runs along time, and each cell is one original frame. A cell's width is how long that frame is on screen, so a last scene that stays a long time looks wide. The gray bar is the bytes that frame uses in the original, and the orange bar is the bytes it uses in the result. Heights use a square-root scale so small frames stay visible.

• The first frame is the biggest: it has to draw the whole screen, so it is always large. In the screen recording sample the orange bars become very low after the first frame, because only the changed parts are stored.
• Hatched cells are frames that are not in the result as their own frame: either they were identical to the previous frame and only their time was merged, or they were dropped by frame thinning. The previous frame stays visible for that time.
• Where bars jump up, the scene changed: in a video GIF, a cell with a suddenly taller bar is a scene where the whole picture changed. If such a stretch is long, thinning frames helps a lot.

Click the map to stop on that frame; the stage then shows the original and the result at the same moment. Use the arrow keys to move one frame at a time and look for scenes where the loss is noticeable.

Common mistakes

• A file that was only renamed to .gif: a PNG, JPG or WebP with its name changed is not a GIF and will not open. To turn several photos into an animation use the GIF maker, and to turn a video into a GIF use the video to GIF converter.
• Thinking half the width means half the file: the pixels drop to a quarter, but the file size depends on how much changes between frames. As the table above shows, a video and a screen recording shrink differently.
• Thinking that dropping frames makes it faster: the time of removed frames is added to the remaining ones, so the playing time stays the same. Only the motion gets less smooth.
• Compressing an already compressed GIF again: shrinking a GIF that was already shrunk with a lossy level piles up the loss. If you still have the original, go from the original to the level you want in one step for a cleaner result.
• Expecting Lossless to always make a file smaller: a GIF that is already well compressed does not get smaller when rewritten. In that case this tool returns the original and says so in the result area.
• Mixing up MB and MiB: a limit of "10MB" can mean 10,000,000 bytes or 10,485,760 bytes depending on the service. Aiming a little below the limit is the safe choice.

Limits

• One GIF at a time, up to 50 MB, 1,000 frames, and width × height × frames of 150 million pixels. Width and height can each be up to 8,000px. These numbers are not limits of the GIF format; they are a range chosen so that this tool does not freeze the browser.
• The sizes in the tables were measured on 2026-10-21 with this tool's engine. The same engine gives the same sizes in any browser, but they can change if the engine is modified.
• The quality of each level is not decided by numbers such as PSNR alone. The same level can look different on different GIFs, so check it yourself on the stage.
• The result is always a GIF. For a long GIF made from video, an MP4 or WebM video or an animated WebP of the same quality is far smaller. web.dev recommends replacing large GIFs on web pages with video. If the place you upload to accepts video, that is the better choice.
• Extra data such as comments and XMP, and interlaced storage, are not kept in the result. The loop count (forever, once, or n times) stays as in the original.
• Playback on the stage is the browser playing two GIFs separately, so in a very long GIF the original and the result can drift slightly apart. To compare the same moment exactly, pause and step through frames.

As of 2026-10-21, the relevant statements in the documents below were checked. The size numbers were measured by shrinking the sample GIFs with this tool's engine.

Sources

• 01W3C — Graphics Interchange Format Version 89aImage descriptor position and size, color table size 2^N+1, disposal methods 0 to 3, delay time (1/100 s), transparent index, LZW codes of at most 12 bits
• 02gifsicle manual — --lossy, --optimizeThe option that shrinks files by changing pixel colors in lossy LZW, and the frame optimization levels
• 03Welch, T. A. (1984). A Technique for High-Performance Data Compression. Computer, 17(6), 8–19LZW compression
• 04Heckbert, P. (1982). Color image quantization for frame buffer display. SIGGRAPH '82, 297–307Median cut color reduction
• 05GitHub Docs — Attaching filesImages and GIFs up to 10MB
• 06web.dev — Replace animated GIFs with video for faster page loadsReplacing large GIFs with video makes them much smaller
• 07WebKit — ScalableImageDecoder.cppA comment saying that frames with a delay of 0.01 s (10 ms) or less are shown as 0.1 s, like Firefox
• 08NIST — Prefixes for binary multipleskilo = 10³, kibi = 2¹⁰

Frequently asked questions

Related tools