Self descript. I know it's already been asked here and here. But apparently it's still an issue. This only started happening to me this week that I've noticed. Per the comments in the linked answer, a hard refresh should fix it but alas, it does not. Firefox 57.0. Works on SE but doesn't work on SO or many of the other sites I visit.

I disabled my add-ons and did a hard refresh but still to no avail. I've exited my browser cleared my temp stuffs as well.

enter image description here

  • Literally the one I linked. Commented Nov 30, 2017 at 14:15
  • I know, just because you linked it does not make it not a duplicate, you are asking the same question.
    – Mark Kirby
    Commented Nov 30, 2017 at 14:16
  • 3
    @MarkKirby actually when a bug is completed/fixed, it's pointless to mark a new same bug as duplicate. Instead, the bug should be re-opened, and reporting it again is valid in this case. Some bugs, like this one, happen over and over, and the team never really got to the bottom of this, just trying temporary fix every time. Commented Nov 30, 2017 at 14:24
  • 1
    @ShadowWizard There's not really anything to "get to the bottom of." We added two new icons to the sprite on Tuesday so all the caches of it need to be updated. All we can do is keep purging caches to make sure everyone is loading the fresh copy. That's not a temporary fix, it's the one and only fix. It just happens to be the same fix every time. But yeah, duplicating it just makes it harder for us to notice it needs purged.
    – animuson StaffMod
    Commented Nov 30, 2017 at 15:50
  • 4
    @animuson so the issue is "keep purging caches to make sure everyone is loading the fresh copy" - I would expect some sure way to do this, without the need to go one by one, which takes long time, during which many people see wrong icons. Not the end of the world, but it doesn't look very good, literally. Commented Nov 30, 2017 at 15:56
  • @animuson: The CSS and sprite sheet URLs have cache breakers that should keep this from happening. But for some reason they aren't. That is a bug, and should be fixed. Commented Dec 2, 2017 at 13:40
  • @Ilmari Those only affect the client. They don't help if a server somewhere has a cache of an old file.
    – animuson StaffMod
    Commented Dec 2, 2017 at 15:07
  • @animuson: Fair enough. I guess that (server caches not getting purged when they should) is the real bug, then. I suppose the data URI embedding I suggested at the bottom of my answer could be a workaround. Commented Dec 2, 2017 at 17:22

1 Answer 1


This keeps happening every time a new site is added. Clearly, something's broken with the sprite sheet update process.

Inspecting the CSS for the site icons, it looks like this (using the SO icon as an example):

.favicon-stackoverflow {
    background-position: 0 -5832px;
.favicon {
    width: 16px;
    height: 16px;
    background-color: transparent;
    background-repeat: no-repeat;
    background-image: url(../../img/favicons-sprite16.png?v=57f32c762460);

The icons are loaded from a single sprite sheet, with each icon element having a distinct background-position that determines which part of the sprite sheet is shown for each site. Apparently, the icons in the sheet are simply listed in alphabetical order, so when new sites are added, the positions of any icons for sites that come later in the alphabet will change. That involves changing both the sprite sheet itself and the background-position in the CSS, and if these somehow get out of sync, the wrong icons will appear.

However, they really shouldn't be getting out of sync, since both the sprite sheet and the CSS file itself have cache breakers in their URLs. See that v=57f32c762460 in the quote above? That's the current sprite sheet version ID, while the CSS file it was quoted from currently has the version ID v=13c0344d1677. What's supposed to happen, when a new site icon is added, is that both of these version IDs are changed. So now, when you load a new page, your browser will see that the CSS URL has changed, and will reload the new version from the SE servers. And then it will see that the sprite sheet URL in that CSS file has also changed, and will reload the sprite sheet, too.

But clearly this isn't always happening. Somehow, the two files are getting out of sync. It looks like either:

  1. the sprite sheet version isn't getting properly updated when new icons are added, causing the browser to use the new icon offsets with an old cached sprite sheet; or
  2. the CSS file version isn't getting updated, causing browsers that happen to have cached the CSS file but not the sprite sheet to use the old offsets with the new sprite sheet.

(The former seems more likely, but the latter is also a possibility. Of course, there could be other possible causes, too, such as the CDN serving stale files for some reason.)

To fix this, some SE developer need to take a close look at the new site deployment process, and figure out why it isn't correctly updating both of these cache breakers (or purging CDN caches, or whatever the actual issue is).

Or, as an alternative solution, SE could get rid of the sprite sheet entirely, and switch to embedding icons in CSS with data URIs. That would get rid of the synchronization issues, and perhaps even improve page loading times. It works for Wikipedia, there's no reason why it couldn't work here too.

  • 1
    I suspect it's much more complicated than that. The cache is server side, Varnish cache used by Fastly which SE are using as host. And there are many different servers, each for different region in the world, that's why most users get the correct resources while others get out of date resources. I have no idea where exactly is the bug, but disappointed SE are not really trying to fix this for real or find a better host with better caching, that does not break for many users every time they make a change. It's not professional, and irritating. Commented Dec 2, 2017 at 17:18

Not the answer you're looking for? Browse other questions tagged .