I was facing the same problem with my GIF encoder/decoder class I wrote some time ago (and improving from time to time). I found out the solution for this just yesterday. The GIF is completely fine the problem is on a modern internet browser’s side. Affected browsers are Opera, IE, and Chrome (didn’t test others).
After some investigation on the matter (by comparing looping and non-looping images), I found out that these browsers’ GIF decoders are ignoring the looping parameters in GIF files. Instead they are depending on an undocumented application extension in the first frame of GIF file.
So the solution is to add this extension command just before first frame image data. Add this chunk:
0x21,0xFF,0x0B,"NETSCAPE","2.0",0x03,0x01,0x00,0x00,0x00
This will force browsers to loop endlessly.
Here is an example:
Hex view so you see how it is added:
The GIF is not sensitive on inserting/reordering non-image chunks of data, so you can insert this before the first image in any place between any other extension. I put it directly after header + palette. Which can be done with C++ or any other language (no re-encoding is needed). For more info see:
- How to find where does Image Block start in GIF images?
- Decode data bytes of GIF87a raster data stream
[Edit by Reed Dunkle]
You can also do it manually with a Hex Editor. I used “Hex Fiend” on macOS Sierra.
Search for 21 F9 in the beginning portions of hex (this is the header). In the photo above, it is 21 F9 04 04 00 00 00 00. Yours could be slightly different, but notice it comes before 2C, which marks the beginning of an image block.
Before the 21 F9… portion, insert the following hex, marked as the “application extension” in the photo above:
21 FF 0B 4E 45 54 53 43 41 50 45 32 2E 30 03 01 00 00 00
Save, and test it.
Addon by Spektre: Beware: 21 F9 marks gfx extension chunk which is optional so it may not be present for all or any frames (but that is really rare these days).