Serious memory leak issue with 24-bit PNG images with alpha transparency in Internet Explorer

In my day job (i.e. the one paying the bills), I encountered a very serious problem in Internet Explorer, which turned out to be a show-stopper in my current project.

Basically, I’m working with a tool for editors where they can open up a sort of wizard/dialog on top of the regular document. In good modern fashion, this is naturally an overlay where the rest of document is dimmed out. The designer had created a sort of checkered background for the dimming, so I cut that image into a small 4 * 4 pixels wide 24-bit PNG image with alpha transparency (i.e. semi-transparent background, no matter what would be behind it). I then repeated that image as the background for the dialog.

We deployed it, it looked good and we went on with our lives. But gradually a number of reports came in that this page was dog slow to work with, you couldn’t even scroll and it would literally take seconds when you clicked a link before anything happened. Also, worth to note is that this only applied to Internet Explorer users (IE 7).

I really had no clue why this would be, because we were doing (or at least trying to do) all the right things with optimizing scripts, minimizing DOM access etc. Desperately thinking about what it could be, I remembered from before that transparency can make things slow, but never like this.

Just to see if it made any difference, I replaced the PNG image with a background color and opacity via CSS (and used the ridiculous code to get opacity in Internet Explorer). We deployed the code and awaited the news of any change.

Lo and behold, all performance problems were gone as if they had never existed! So, my word of warning to you is:

Be very very careful when you use 24-bit PNG images with alpha transparency in Internet Explorer, because apparently there is some serious memory leak issue/bug with it.


  • That is very interesting, and just a little disturbing.

    Robert, have you verified this bug against IE8 (in IE8 rendering mode), where there would (I hope) not be a fix, as Microsoft have removed a lot of their own extensions???


    For performance reasons, I always create larger tile images, as IE also seems to slow down when tiling background images. Consider how many loops a tiling method has to do on a 4×4 image compared to a 100×100 image for your screen resolution. Or perhaps a better example would be a background gradient image of 2×400 compared to 50×400. The added "weight" of the image won't be that much larger, but the site will feel faster for IE users.

  • NICCAI says:

    Had this problem before – were mouseovers really slow? I solved this by making the tiled png much larger (try 400×400 or whatever works for the tiling). In our tests, the excessive tiling cause IE to scream.

  • Pete says:

    Yep, I had this problem too wth tiling in IE.

    Making the tile much bigger solves the problem — just another IE related gotcha to work-around 🙁

  • In my experience the memory leak issue could be fixed with adding a unload method which clears the filter attributes. This is how qooxdoo do this as well. Might work for you, too.

  • Florent V. says:

    Same as Morgan: i just never use 4*4px images, or 1*200px images or the like. The performance issues happen with any such repeated background image, on several browsers and platforms (i remember that kind of issue with Firefox 2 on Linux, for instance), and get worse with low-performing hardware.

  • Oops, just found out that there was no mention of AlphaImageLoader at all. But as PNGs in IE7 have the same issues as when dealing with AlphaImageLoader in IE6 (not combinable with other filters e.g. gray or opacity) the same issue might apply here and a reset of that property might help as well.

  • NICCAI says:

    Couple of other things. Shrink the viewport way down and see if performance improves, if so, it is certainly tiling – or a combination of tilings (do you use a small png elsewhere too?). Other than that IE really isn't fond of fixed position and alpha transparency. If your overlay is using this type of positioning, try absolute as a debug point.

  • Nathan Smith says:

    Another thing you can do (if the markup permits) is absolutely position an [img] tag atop the page. It could be a 1×1 PNG, and you could forcibly resize it to 100% x 100%. That would be the best of both worlds: Small file-size, and zero tiling.

  • Great article. Seems like we never get rid of the ie-vs-png curse …

    Aside, I would love an article about javascript performance. It is a really important chapter in javascript very few bring up. Me myself work with HTML-documents containing over 4000 elements, and one must be very careful when scripting. I find it very frustrating that so few write good articles about it.

  • It does have something to do about the AlphaImageLoader (if it has the same program in IE7). I'll do tests later this week with tiling PNG vs GIF images in IE. I think that IE tries to load and read the alpha channels of any PNG, and the smaller it is, the more there are on the page, the heavier it gets for that bastard to calculate it all. Microsoft isn't known for it's good graphic management.

    As I mentioned on Twitter, when I used a PNG-8 file with 8×8 pixels i got redraw slowdowns. 16×16 had less, and making the PNG 32×32 even less so.

  • Robert Nyman says:

    Thanks for good input, guys! Interesting that so many said that larger images seem to work better. It still matters with image-size, though, and I really think we shouldn't have this situation to begin with.

    Also thanks for suggestion about absolute positioning.

    I should mention that this problem was most prevalent with "slower" computers, meaning 1-2 GB of RAM.


    No specific testing with IE 8, this has mostly been a very pragmatic experience where virtually everyone uses IE 7.


    Yes, mouse movements were extremely sluggish. And i dodn't really need to check if tiling, I knew it as soon as it was removed, because the difference were so extremely noticeable.

    Sebastian, Nathan,

    Interesting – resetting/removing properties on unload might be a good improvement to it.


    Yes, it would be interesting. Generally, people know that IE is very slow there too (shocker) and that everyone is good at it. One day, I hope I, or someone else, will delve deeper into it.


    I would love to see some tests! 🙂

  • IE8 and Google Chrome definitely have issues with 24-bit PNGs on my WinXP system. I'm currently developing a website for a client and using the jQuery Fade In/Fade Out Effect on some 24-bit images. In IE8, the images have a black outline where the alpha channel exists. With Chrome, there's white outline on a smaller PNG (1×40 pixels tiling). Larger PNGs appear fine (280×82 pixels).

    My temporary fix is to create transparent GIFs when animating with jQuery effects. And use 24-bit PNGs for static images. So far, Firefox and Safari appear to display static and 24-bit PNGs properly.

  • Robert Nyman says:


    Interesting. Thanks for sharing!

  • An edit to my last post:

    So far, Firefox and Safari appear to display static and animated 24-bit PNGs properly.

  • Robert Nyman says:



  • Jonathan says:


    Thanks so much for the post and replies. I've been working on an image fader for the last few hours and I was having serious issues with IE 7. After hours of swapping pieces out, disabling code, and css I came to the conclusion that it had something to do with my background-images. That being said I stumbled across this site and found out that it was directly related to my background images that were tiled, which in some cases were 2 x 20. When I shrunk the view port to only show the portion of the site where the fading was happening and I disabled a couple of the tiled backgrounds, I noticed "normal" performance.

    Looks like I'll be going back to Photoshop to export some larger background-image tiles.

    Thanks so much! I was certain something was wrong with the script. Should have known… IE gets me everytime!

  • Robert Nyman says:


    Glad it helped! And I agree: there seems to be no end to the issues caused by Internet Explorer…

  • Jonathan says:

    This is a follow up post. I exported the images to larger sizes. For the tiled images I was able to get both dimensions to be 64px or greater. I've found that this does increase performance, but it does not solve the problem completely. The fading between images is still very slow, especially compared to Firefox. I've searched the internet for a decent fix, but it seems there is currently no way around the performance issue, without completely abandoning the tiled PNGs.

  • […] The problem with PNG images is, beside a superfluous HTTP request, that images are way, way more larger in file size than one or two lines of CSS code – especially considering that the image has to be a bit larger to avoid serious memory leak issues with 24-bit PNG images with alpha transparency in Internet Explorer. […]

  • Thanks a lot for the posts 🙂 ….

    I was going to use opacity but will try larger tiles.

  • Robert Nyman says:


    You're welcome! Good luck!

  • Paul de Vries says:

    Thanks alot! I was using a tile of 10×10 and changed that to 400×200 and that solved the mem leak. Oww and file size went from 1KB to 2KB.. No big deal this days 🙂

  • Robert Nyman says:


    A price worth to pay to get around this problem. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.