I have a gif that I want to modify in Photoshop:

ASCII game animations

When I'm ready to save, I use "Save for Web" and look for ways to optimise it. These are the settings that are loaded automatically. The estimated file size is 1.871M.

Save for Web settings. "Transparency" is checked and the file size is 1.871M

I uncheck "Transparency" since there is none in the image, thinking that this might reduce the size. But instead, the size is effectively doubled. The new estimated file size is 3.739M.

Save for Web settings. "Transparency" is unchecked and the file size is 3.739M

So what I'd like to know is... why?

Update 1:

I've fiddled around with different images after reading Yorik's comment

“. . . AFIAK gifs do not store the whole image per-frame, but rather sub-frames that change.”

It does seem like that's the case, since testing with this gif (where the entire image changes every frame) gives a much smaller difference between images saved with and without transparency (source):

A solid background transitions from red to blue.

  • With transparency: 531 bytes
  • Without transparency: 502 bytes

That's a saving of ~5%, which is much less than the ~50% savings that we get with the image in my original question.

So it appears that transparency allows for some optimization related to changes in the image. I can guess how, but I'd rather hear from someone with a deeper understanding of the gif format.

  • I always wondered that myself...
    – Luciano
    Commented Jul 31, 2018 at 15:15
  • Can you save both and confirm that the estimates are correct? Commented Jul 31, 2018 at 15:27
  • 1
    I do not know for sure so I won't answer and mislead, but my first instinct is that there is an optimization possible with transparency: you can potentially reduce the bounding box when there is transparency. See for example the third illustration in this question: ( stackoverflow.com/questions/44555789 ) which is going to be a large gain in file size. AFIAK gifs do not store the whole image per-frame, but rather sub-frames that change.
    – Yorik
    Commented Jul 31, 2018 at 15:35
  • @DigitalLightcraft Yes! I've saved them and the file sizes according to WIndows are 1.87M with transparency, and 3.73M without. This is also reproducable using the image included in the question: i.sstatic.net/EFkCi.gif
    – Obscerno
    Commented Jul 31, 2018 at 15:52
  • @Yorik I think you're on to something. I tried the same test on the second gif on this page: blog.mattbierner.com/scanline-gif (the one of the solid colors), and the savings dropped by a lot. With that image, transparency = 531 bytes, and no transparency = 502 bytes. It looks like any part of the background that doesn't change can be used to save bytes in later frames. I'll add a tag to see if we can find anyone who knows more about image compression.
    – Obscerno
    Commented Aug 1, 2018 at 18:50

2 Answers 2


Got some free time and decided to skim through the GIF Specification. For a layman (i.e. me) it's pretty dense. That said, I think I've found what makes the optimization possible.

For context, under the general description section it states:

The Graphics Interchange Format is defined in terms of blocks and sub-blocks which contain relevant parameters and data used in the reproduction of a graphic.

It goes on to describe the different types of blocks and sub-blocks. From what I can tell, "Graphic Control Extension" blocks are the ones that make animation possible and essentially act as frames. They allow for a "Delay Time" value, and also allow for a "Transparency Index", which is described as:

The Transparency Index is such that when encountered, the corresponding pixel of the display device is not modified and processing goes on to the next pixel. The index is present if and only if the Transparency Flag is set to 1.

Interesting! So in the GIF format, tranparency means "don't draw anything in this space".

The final piece of the puzzle is the Graphic Control Extension's "Disposal Method":

Disposal Method - Indicates the way in which the graphic is to be treated after being displayed.


  • 0 - No disposal specified. The decoder is not required to take any action.
  • 1 - Do not dispose. The graphic is to be left in place.
  • 2 - Restore to background color. The area used by the graphic must be restored to the background color.
  • 3 - Restore to previous. The decoder is required to restore the area overwritten by the graphic with what was there prior to rendering the graphic.
  • 4-7 - To be defined.

If the previous frame isn't disposed of, transparent pixels will allow that frame to show through. But if the previous frame is replaced with the background color...

ASCII game animation, for every frame only displaying the ones that change.

As you can see, only the pixels that have changed since the last frame are updated, and the rest have been left unaltered (transparent). That's a lot less information to store.

When transparency is disabled, every frame has to be drawn in its entirety. So that's why enabling transparency in an animated gif saves space.

If you're reading this, you might also want to check out this article, which goes over how the gif disposal method works in plain English. It does it in the context of a gif editing program called GIFBuilder but it's still good info!

Finally, if anyone else has more insight into this please jump in.

  • This deserves way more upvotes! Fascinating answer, I never would have guessed this
    – Tim Mackey
    Commented Jan 17, 2019 at 0:17

That's about the file you provided.

Almost the colors have some transparency, but black color.

Use the color picker in opacity mode to verify it by yourself.

You can verify it in the color pallete while you're saving fo web. The last color is a transparency.

The image below shows how I found it:

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.