Editing GIF

{{short description|Bitmap image file format family}}
{{Other uses}}
{{Use dmy dates|date=September 2020}}
{{Infobox file format
| icon =
| iconcaption =
| icon_size =
| screenshot = Rotating earth (large).gif
| screenshot_size = 200px
| caption = An [[#Animated GIF|animated GIF]] of a [[Earth's rotation|rotating globe]]
|_noextcode =
| extension = {{code|.gif}}
<!-- or: | extensions = -->
|_nomimecode =
| mime = {{code|image/gif}}
| type code = {{code|GIFf}}
| uniform_type = com.compuserve.gif
| conforms_to =
| magic = <code>GIF87a</code>/<code>GIF89a</code>
| developer = [[CompuServe]]
| released = {{start date and age|df=yes|1987|6|15}}<ref name="87aSpec">{{cite web |url= http://www.w3.org/Graphics/GIF/spec-gif87.txt |title= Graphics Interchange Format, Version 87a |date= 15 June 1987 |publisher= [[W3C]] |access-date= 13 October 2012 |archive-date= 22 December 2018 |archive-url= https://web.archive.org/web/20181222025600/http://www.w3.org/Graphics/GIF/spec-gif87.txt |url-status= live }}</ref>
| latest_release_version = 89a
| latest_release_date = {{start date and age|1989}}<ref name="89aSpec">{{cite web |url= http://www.w3.org/Graphics/GIF/spec-gif89a.txt |title= Graphics Interchange Format, Version 89a |date= 31 July 1990 |publisher= [[W3C]] |access-date= 6 March 2009 |archive-date= 22 December 2018 |archive-url= https://web.archive.org/web/20181222182620/http://www.w3.org/Graphics/GIF/spec-gif89a.txt |url-status= live }}</ref>
| genre = [[Lossless data compression|lossless]] [[Raster graphics|bitmap]] [[Graphics file format|image format]]
| container_for =
| contained_by =
| extended_from =
| extended_to =
| standard =
<!-- or: | standards = -->
| free =
| url = {{URL|https://www.w3.org/Graphics/GIF/spec-gif89a.txt}}
}}
<!-- IMPORTANT: PRONUNCIATION CHANGES WITHOUT DISCUSSION WILL BE REVERTED

If you have a good reason for wanting this article to focus on one particular pronunciation, you are welcome to raise your concerns on the talk page and start a discussion about it. Maybe you will even change the current consensus on this point and then be able to change this article. Any changes made to the article without discussion will be reverted.

Thank you for listening. -->
The '''Graphics Interchange Format''' ('''GIF'''; {{IPAc-en|ɡ|ɪ|f}} {{respell|GHIF}} or {{IPAc-en|dʒ|ɪ|f}} {{respell|JIF}}, {{xref|see {{slink||Pronunciation}}}}) is a [[Raster graphics|bitmap]] [[Image file formats|image format]] that was developed by a team at the online services provider [[CompuServe]] led by American computer scientist [[Steve Wilhite]] and released on June 15, 1987.<ref name="87aSpec" />

The format can contain up to [[8-bit color|8 bits per pixel]], allowing a single image to reference its own [[Palette (computing)|palette]] of up to 256 different colors chosen from the [[24-bit color|24-bit]] [[RGB color model|RGB color space]]. It can also represent multiple images in a file, which can be used for [[animation]]s, and allows a separate palette of up to 256 colors for each frame. These palette limitations make GIF less suitable for reproducing color photographs and other [[Image gradient|images with color gradients]] but well-suited for simpler images such as graphics or logos with solid areas of color.

GIF images are compressed using the [[Lempel–Ziv–Welch]] (LZW) [[lossless data compression]] technique to reduce the file size without degrading the visual quality.

While once in widespread usage on the [[World Wide Web]] because of its wide implementation and portability between applications and operating systems, usage of the format has declined for space and quality reasons, often being replaced with video formats such as the [[MP4 file format]]. These replacements, in turn, are sometimes termed "GIFs" despite having no relation to the original file format.<ref>{{cite web|url=https://www.theatlantic.com/technology/archive/2022/10/using-reaction-gifs-over-tumblr-giphy/671680/|title=The GIF Is on Its Deathbed|last=Tiffany|first=Kaitlyn|publisher=[[The Atlantic]]|date=2022-10-07|access-date=2023-10-21}}</ref>

==History==
{{Further|GIF#Unisys and LZW patent enforcement|label1=§ Unisys and LZW patent enforcement}}

[[CompuServe]] introduced GIF on 15 June 1987 to provide a color image format for their file downloading areas. This replaced their earlier [[run-length encoding]] format, which was black and white only. GIF became popular because it used [[Lempel–Ziv–Welch]] [[data compression]]. Since this was more efficient than the run-length encoding used by [[PCX]] and [[MacPaint]], fairly large images could be downloaded reasonably quickly even with slow [[modem]]s.

The original version of GIF was called 87a.<ref name="87aSpec" /> This version already supported multiple images in a stream.

In 1989, CompuServe released an enhanced version, called 89a,<ref name="89aSpec" /> This version added:
* support for animation delays
* [[Transparency (graphic)|transparent]] background colors
* storage of application-specific metadata
* allowing text labels as text (not embedding them in the graphical data). As there is little control over display fonts, however, this feature is rarely used.

The two versions can be distinguished by looking at the first six [[byte]]s of the file (the "[[magic number (programming)|magic number]]" or signature), which, when interpreted as [[ASCII]], read "GIF87a" or "GIF89a", respectively.

CompuServe encouraged the adoption of GIF by providing downloadable conversion utilities for many computers. By December 1987, for example, an [[Apple IIGS]] user could view pictures created on an [[Atari ST]] or [[Commodore 64]].<ref name="caa198712">{{cite news | url=https://archive.org/stream/COMPUTEs_Apple_Applications_Vol._5_No._2_Issue_6_1987-12_COMPUTE_Publications_US#page/n11/mode/2up | title=Online Art | work=Compute!'s Apple Applications | date=December 1987 | access-date=14 September 2016 | pages=10}}</ref> GIF was one of the first two image formats commonly used on Web sites, the other being the black-and-white [[XBM]].<ref>{{Cite book|title=Ajax: The Definitive Guide: Interactive Applications for the Web|last=Holdener III|first=Anthony|publisher=O'Reilly Media|year=2008|isbn=978-0596528386}}</ref>

In September 1995 [[Netscape (web browser)#Release history|Netscape Navigator]] 2.0 added [[#Animated GIF|the ability for animated GIFs to loop]].

While GIF was developed by [[CompuServe]], it used the [[Lempel–Ziv–Welch]] (LZW) [[lossless data compression]] algorithm patented by [[Unisys]] in 1985. Controversy over the licensing agreement between [[Unisys]] and [[CompuServe]] in 1994 spurred the development of the [[Portable Network Graphics]] (PNG) standard. In 2004, all patents relating to the proprietary compression used for GIF expired.

The feature of storing multiple images in one file, accompanied by control data, is used extensively on the Web to produce simple [[computer animation|animations]].

The optional [[Interlacing (bitmaps)|interlacing]] feature, which stores image scan lines out of order in such a fashion that even a partially downloaded image was somewhat recognizable, also helped GIF's popularity,<ref>{{Cite book|title=Encyclopedia of Multimedia|last=Furht|first=Borko|publisher=Springer|year=2008|isbn=978-0387747248}}</ref> as a user could abort the download if it was not what was required.

In May 2015 [[Facebook]] added support for GIF.<ref>{{cite magazine |url=https://www.wired.com/2015/05/real-gif-posting-on-facebook/ |title=You Can Finally, Actually, Really, Truly Post GIFs on Facebook |magazine=[[Wired (magazine)|Wired]] |first=Molly |last=McHugh |date=2015-05-29 |access-date=2015-05-29 |archive-date=30 May 2015 |archive-url=https://web.archive.org/web/20150530004146/http://www.wired.com/2015/05/real-gif-posting-on-facebook/ |url-status=live }}</ref><ref>{{cite web |url=https://techcrunch.com/2015/05/29/facebook-confirms-it-will-officially-support-gifs |title=Facebook Confirms It Will Officially Support GIFs |date=2015-05-29 |access-date=2015-05-29 |first=Sarah |last=Perez |publisher=[[TechCrunch]] |archive-date=30 May 2015 |archive-url=https://web.archive.org/web/20150530043012/http://techcrunch.com/2015/05/29/facebook-confirms-it-will-officially-support-gifs/ |url-status=live }}</ref> In January 2018 Instagram also added GIF stickers to the story mode.<ref>{{Cite web|url=https://instagram-press.com/blog/2018/01/23/introducing-gif-stickers/|title=Introducing GIF Stickers|date=2018-01-23|website=Instagram|language=en-US|access-date=2019-09-19|archive-date=12 December 2019|archive-url=https://web.archive.org/web/20191212103358/https://instagram-press.com/blog/2018/01/23/introducing-gif-stickers/|url-status=live}}</ref>

==Terminology==
As a [[noun]], the word ''GIF'' is found in the newer editions of many dictionaries. In 2012, the American wing of the [[Oxford University Press]] recognized ''GIF'' as a [[verb]] as well, meaning "to create a GIF file", as in "GIFing was the perfect medium for sharing scenes from the [[Summer Olympics]]". The press's lexicographers voted it their [[word of the year]], saying that GIFs have evolved into "a tool with serious applications including research and journalism".<ref>{{cite web |url=http://blog.oxforddictionaries.com/press-releases/us-word-of-the-year-2012/ |title=Oxford Dictionaries USA Word of the Year 2012 |website=OxfordWords blog |publisher=Oxford American Dictionaries |date=2012-11-13 |access-date=2013-05-01 |archive-date=3 August 2014 |archive-url=https://web.archive.org/web/20140803083637/http://blog.oxforddictionaries.com/press-releases/us-word-of-the-year-2012/ |url-status=dead }}</ref><ref>{{cite news |last=Flood |first=Alison |url=https://www.theguardian.com/books/booksblog/2012/nov/14/gif-america-word-year-omnishambles |title=''Gif'' is America's word of the year? Now that's what I call an omnishambles |department=Books blog |work=[[The Guardian]] |date=2013-04-27 |access-date=2013-05-01 |location=London |archive-date=1 December 2016 |archive-url=https://web.archive.org/web/20161201172504/https://www.theguardian.com/books/booksblog/2012/nov/14/gif-america-word-year-omnishambles |url-status=live }}</ref>

===Pronunciation===
{{Main|Pronunciation of GIF}}
[[File:White House Tumblr launch image.jpg|thumbnail|right|A humorous infographic announcing the 2013 launch of a [[Tumblr]] account for the [[Executive Office of the President of the United States|White House]] suggests pronouncing ''GIF'' with a hard ''g''.]]

The pronunciation of the first letter of ''GIF'' has been disputed since the 1990s. The most common pronunciations in English are {{IPAc-en|dʒ|ɪ|f|audio=Pronunciation of jif.ogg}} (with a [[Voiced postalveolar affricate|soft ''g'']] as in ''gin'') and {{IPAc-en|g|ɪ|f|audio=Pronunciation of gif.ogg}} (with a [[Voiced velar plosive|hard ''g'']] as in ''gift''), differing in the [[phoneme]] represented by the letter ''G''. The creators of the format pronounced the acronym ''GIF'' as {{IPAc-en|dʒ|ɪ|f}}, with a [[Voiced postalveolar affricate|soft ''g'']], with Wilhite stating that he intended for the pronunciation to deliberately echo the American [[peanut butter]] brand [[Jif (peanut butter)|Jif]], and CompuServe employees would often quip "choosy developers choose GIF", a spoof of Jif's television commercials.<ref name="olsen">{{cite web | url = http://www.olsenhome.com/gif/ | title = The GIF Pronunciation Page | first = Steve | last = Olsen | access-date = 6 March 2009 | archive-date = 25 February 2009 | archive-url = https://web.archive.org/web/20090225075707/http://www.olsenhome.com/gif/ | url-status = live }}</ref> However, the word is widely pronounced as {{IPAc-en|ɡ|ɪ|f}}, with a [[Voiced velar stop|hard ''g'']],<ref name=BBC20130522>{{cite news|url=https://www.bbc.co.uk/news/technology-22620473|title=Gif's inventor says ignore dictionaries and say 'Jif'|work=BBC News|date=2013-05-22|access-date=2013-05-22|archive-date=27 June 2018|archive-url=https://web.archive.org/web/20180627083454/https://www.bbc.co.uk/news/technology-22620473|url-status=live}}</ref> and polls have generally shown that this hard ''g'' pronunciation is more prevalent.<ref>{{Cite news|last=Buck|first=Stephanie|date=October 21, 2014|title=70 percent of people worldwide pronounce ''GIF'' with a hard ''g''|work=[[Mashable]]|url=https://mashable.com/archive/mispronounced-words-tech|access-date=December 24, 2021|archive-date=December 23, 2021|archive-url=https://web.archive.org/web/20211223162234/https://mashable.com/archive/mispronounced-words-tech|url-status=live}}</ref><ref>{{Cite journal |last=van der Meulen |first=Marten |date=May 22, 2019 |title=Obama, SCUBA or gift?: Authority and argumentation in online discussion on the pronunciation of ''GIF'' |url=https://www.cambridge.org/core/journals/english-today/article/obama-scuba-or-gift/0057DB6B7B1FAABBE3112342FE14E27D |journal=[[English Today]] |volume=36 |issue=1 |pages=45–50 |access-date=22 May 2022 |archive-date=24 May 2022 |archive-url=https://web.archive.org/web/20220524072220/https://www.cambridge.org/core/journals/english-today/article/obama-scuba-or-gift/0057DB6B7B1FAABBE3112342FE14E27D |url-status=live }}</ref>

''[[Dictionary.com]]''<ref>{{cite web |url=http://dictionary.reference.com/browse/GIF |title=GIF |work=The American Heritage Abbreviations Dictionary, Third Edition |publisher=Houghton Mifflin Company |year=2005 |access-date=2007-04-15 |archive-date=3 September 2011 |archive-url=https://web.archive.org/web/20110903171835/http://dictionary.reference.com/browse/GIF |url-status=live }}</ref> cites both pronunciations, indicating {{IPAc-en|dʒ|ɪ|f}} as the primary pronunciation, while ''Cambridge Dictionary of American English''<ref name="cambridgedict">{{cite web |url=http://dictionary.cambridge.org/us/dictionary/business-english/gif?q=gif |title=GIF |work=The Cambridge Dictionary of American English |publisher=Cambridge University Press |access-date=2014-02-19 |archive-date=27 February 2014 |archive-url=https://web.archive.org/web/20140227180258/http://dictionary.cambridge.org/us/dictionary/business-english/gif?q=gif |url-status=live }}</ref> offers only the hard-''g'' pronunciation. ''[[Merriam-Webster's Collegiate Dictionary]]''<ref>{{cite web|title=Gif - Definition from the Merriam-Webster Dictionary|url=http://www.merriam-webster.com/dictionary/gif|work=Merriam-Webster Dictionary|publisher=Merriam-Webster, Incorporated|access-date=6 June 2013|archive-date=22 October 2013|archive-url=https://web.archive.org/web/20131022062546/http://www.merriam-webster.com/dictionary/gif|url-status=live}}</ref> and Oxford Dictionaries cite both pronunciations, but place the hard ''g'' first: {{IPAc-en|g|ɪ|f|,_|dʒ|ɪ|f}}.<ref name="oxforddict">{{cite web|url=http://www.oxforddictionaries.com/definition/english/GIF|title=GIF|work=Oxford Dictionaries Online|publisher=Oxford University Press|access-date=7 October 2014|archive-date=12 October 2014|archive-url=https://web.archive.org/web/20141012205125/http://www.oxforddictionaries.com/definition/english/GIF|url-status=dead}}</ref><ref>{{Cite web|last=|first=|date=|title=gif noun - Definition, pictures, pronunciation and usage notes {{!}} Oxford Advanced Learner's Dictionary|url=https://www.oxfordlearnersdictionaries.com/definition/english/gif|url-status=live|archive-url=https://web.archive.org/web/20201124151618/https://www.oxfordlearnersdictionaries.com/definition/english/gif|archive-date=24 November 2020|access-date=2021-02-06|website=Oxford Learner's Dictionaries}}</ref><ref>{{Cite web|last=|first=|date=|title=GIF {{!}} Definition of GIF by Oxford Dictionary|url=https://www.lexico.com/definition/gif|url-status=dead|archive-url=https://web.archive.org/web/20210213163951/https://www.lexico.com/definition/gif|archive-date=13 February 2021|access-date=2021-02-06|website=[[Lexico]]|language=en}}</ref><ref>{{Cite book|last=|first=|url=https://www.worldcat.org/oclc/729551189|title=Oxford Dictionary of English|publisher=Oxford University Press|year=2010|isbn=9780199571123|editor-last=Stevenson|editor-first=Angus|edition=3rd|location=|pages=|oclc=729551189|access-date=6 February 2021|archive-date=23 August 2022|archive-url=https://web.archive.org/web/20220823125918/https://www.worldcat.org/title/729551189|url-status=live}}</ref> The ''[[New Oxford American Dictionary]]'' gave only {{IPAc-en|dʒ|ɪ|f}} in its second edition<ref>{{cite book |author=<!--Staff writer(s); no by-line.--> |title=The New Oxford American Dictionary |edition=2nd |publisher=Oxford University Press |page=711 |date=2005 }}</ref> but updated it to {{IPAc-en|dʒ|ɪ|f|,_|g|ɪ|f}} in the third edition.<ref>{{cite book |title=The New Oxford American Dictionary |edition=3rd |date=2012}} (part of the Macintosh built-in dictionaries).</ref>

The disagreement over the pronunciation has led to heated Internet debate. On the occasion of receiving a lifetime achievement award at the [[2013 Webby Awards]] ceremony, Wilhite publicly rejected the hard-''g'' pronunciation;<ref name=BBC20130522 /><ref>{{cite news|last=O'Leary|first=Amy|title=An Honor for the Creator of the GIF|url=http://bits.blogs.nytimes.com/2013/05/21/an-honor-for-the-creator-of-the-gif/?smid=tw-nytimes|newspaper=The New York Times|access-date=22 May 2013|date=21 May 2013|archive-date=22 May 2013|archive-url=https://web.archive.org/web/20130522145554/http://bits.blogs.nytimes.com/2013/05/21/an-honor-for-the-creator-of-the-gif/?smid=tw-nytimes|url-status=live}}</ref><ref name=LAT20131204>{{cite news |url=http://www.latimes.com/nation/shareitnow/la-sh-alex-trebek-gif-pronunciation-jeopardy-20131204,0,1162165.story#axzz2mYD3tX3M |title='Jeopardy' wades into 'GIF' pronunciation battle |work=[[Los Angeles Times]] |access-date=2013-12-04 |first=Daniel |last=Rothberg |date=4 December 2013 |archive-date=6 December 2013 |archive-url=https://web.archive.org/web/20131206004148/http://www.latimes.com/nation/shareitnow/la-sh-alex-trebek-gif-pronunciation-jeopardy-20131204,0,1162165.story#axzz2mYD3tX3M |url-status=live }}</ref> his speech led to more than 17,000 posts on [[Twitter]] and dozens of news articles.<ref>{{cite news | url=http://bits.blogs.nytimes.com/2013/05/23/battle-over-gif-pronunciation-erupts/?_r=0 | work=The New York Times | first=Amy | last=O'Leary | title=Battle Over 'GIF' Pronunciation Erupts | date=23 May 2013 | access-date=5 December 2013 | archive-date=16 December 2013 | archive-url=https://web.archive.org/web/20131216170719/http://bits.blogs.nytimes.com/2013/05/23/battle-over-gif-pronunciation-erupts/?_r=0 | url-status=live }}</ref> The [[White House]]<ref name=BBC20130522 /> and the TV program ''[[Jeopardy!]]'' also entered the debate in 2013.<ref name=LAT20131204 /> In February 2020, [[The J.M. Smucker Company]], the owners of the Jif brand, partnered with the animated image database and search engine [[Giphy]] to release a limited-edition "Jif vs. GIF" ([[hashtag]]ged as #JIFvsGIF) jar of peanut butter that had a label humorously declaring the soft-''g'' pronunciation to refer exclusively to the peanut butter, and ''GIF'' to be exclusively pronounced with the hard-''g'' pronunciation.<ref name="Jif CNN">{{cite web|last=Valinsky|first=Jordan|title=Jif settles the great debate with a GIF peanut butter jar|url=https://www.cnn.com/2020/02/25/business/jif-gif-peanut-butter-trnd/index.html|website=[[CNN]]|access-date=2020-02-25|date=2020-02-25|df=mdy-all|archive-date=25 February 2020|archive-url=https://web.archive.org/web/20200225173743/https://www.cnn.com/2020/02/25/business/jif-gif-peanut-butter-trnd/index.html|url-status=live}}</ref>

==Usage==
GIFs are suitable for sharp-edged line art with a limited number of colors, such as logos. This takes advantage of the format's lossless compression, which favors flat areas of uniform color with well defined edges.<ref name=karunya2012>{{cite conference|chapter=Comparison of platform independent electronic document distribution techniques|first1=D.R.|last1=Marur|first2=V.|last2=Bhaskar|title=2012 International Conference on Devices, Circuits and Systems (ICDCS)|date=March 2012|conference=International Conference on Devices, Circuits and Systems (ICDCS)|conference-url=http://www.ieee.org/conferences_events/conferences/conferencedetails/index.htm?Conf_ID=19586|book-title=Devices, Circuits and Systems (ICDCS)|publisher=IEEE|location=Karunya University; Coimbatore, India|pages=297–301|isbn=9781457715457|doi=10.1109/ICDCSyst.2012.6188724|access-date=11 March 2015|archive-date=2 July 2017|url=http://www.ieee.org/conferences_events/conferences/conferencedetails/index.htm?Conf_ID=19586|archive-url=https://web.archive.org/web/20170702070125/http://www.ieee.org/conferences_events/conferences/conferencedetails/index.htm?Conf_ID=19586|url-status=live}}</ref> They can also be used to store low-color [[Sprite (computer graphics)|sprite]] data for games.<ref name=proandroid11>{{cite book|author1=S. Chin|author2=D. Iverson|author3=O. Campesato|author4=P. Trani|title=Pro Android Flash|date=2011|publisher=Apress|location=New York|isbn=9781430232315|page=350|url=http://yuliana.lecturer.pens.ac.id/Android/Buku/Pro-Android-Flash.pdf|access-date=11 March 2015|archive-date=2 April 2015|archive-url=https://web.archive.org/web/20150402110502/http://yuliana.lecturer.pens.ac.id/Android/Buku/Pro-Android-Flash.pdf|url-status=live}}</ref> GIFs can be used for small animations and low-resolution video clips, or as reactions in online messaging used to convey emotion and feelings instead of using words. They are popular on social media platforms such as [[Tumblr]],<ref>{{cite book |last1=Bakhshi |first1=Saeideh |last2=Shamma |first2=David A. |last3=Kennedy |first3=Lyndon |last4=Song |first4=Yale |last5=de Juan |first5=Paloma |last6=Kaye |first6=Joseph "Jofish" |title=Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems |chapter=Fast, Cheap, and Good: Why Animated GIFs Engage Us |date=7 May 2016 |pages=575–586 |doi=10.1145/2858036.2858532 |isbn=9781450333627 |s2cid=7417853 |chapter-url=https://doi.org/10.1145/2858036.2858532 |access-date=17 August 2022}}</ref> [[Facebook]] and [[Twitter]].<ref>{{cite journal |last1=Highfield |first1=Tim |last2=Leaver |first2=Tama |title=Instagrammatics and digital methods: studying visual social media, from selfies and GIFs to memes and emoji |journal=Communication Research and Practice |date=2016 |volume=2 |issue=1 |pages=47–62 |doi=10.1080/22041451.2016.1155332 |s2cid=148538216 |url=https://doi.org/10.1080/22041451.2016.1155332 |access-date=17 August 2022|hdl=20.500.11937/36939 |hdl-access=free }}</ref>

==File format==
Conceptually, a GIF file describes a fixed-sized graphical area (the "logical screen") populated with zero or more "images". Many GIF files have a single image that fills the entire logical screen. Others divide the logical screen into separate sub-images. The images may also function as animation frames in an animated GIF file, but again these need not fill the entire logical screen.

GIF files start with a fixed-length header ("GIF87a" or "GIF89a") giving the version, followed by a fixed-length Logical Screen Descriptor giving the pixel dimensions and other characteristics of the logical screen. The screen descriptor may also specify the presence and size of a Global Color Table (GCT), which follows next if present.

Thereafter, the file is divided into segments of the following types, each introduced by a 1-byte sentinel:
* An image (introduced by 0x2C, an ASCII comma {{code|','}})
* An extension block (introduced by 0x21, an ASCII exclamation point {{code|'!'}})
* The trailer (a single byte of value 0x3B, an ASCII semicolon {{code|';'}}), which should be the last byte of the file.

An image starts with a fixed-length Image Descriptor, which may specify the presence and size of a Local Color Table (which follows next if present). The image data follows: one byte giving the bit width of the unencoded symbols (which must be at least 2 bits wide, even for bi-color images), followed by a series of sub-blocks containing the LZW-encoded data.

Extension blocks (blocks that "extend" the 87a definition via a mechanism already defined in the 87a spec) consist of the sentinel, an additional byte specifying the type of extension, and a series of sub-blocks with the extension data. Extension blocks that modify an image (like the Graphic Control Extension that specifies the optional animation delay time and optional transparent background color) must immediately precede the segment with the image they refer to.

Each sub-block begins with a byte giving the number of subsequent data bytes in the sub-block (1 to 255). The series of sub-blocks is terminated by an empty sub-block (a 0 byte).

This structure allows the file to be parsed even if not all parts are understood. A GIF marked 87a may contain extension blocks; the intent is that a decoder can read and display the file without the features covered in extensions it does not understand.

The full detail of the file format is covered in the GIF specification.<ref name="89aSpec"/>

==Palettes==
[[File:Sunflower as gif websafe.gif|thumb|right|An example of a GIF image saved with a [[web-safe colors|web-safe palette]] and [[dither]]ed using the [[Floyd–Steinberg dithering|Floyd–Steinberg]] method; as a consequence of the relatively few colors allowed in such an image, the image's [[Contrast (vision)|contrast]] and [[colorfulness]] are noticeably poor.]]
GIF is palette-based: the colors used in an image (a frame) in the file have their [[RGB]] values defined in a [[Palette (computing)|palette table]] that can hold up to 256 entries, and the data for the image refer to the colors by their indices (0–255) in the palette table. The color definitions in the palette can be drawn from a color space of millions of shades (2<sup>24</sup> shades, 8 bits for each primary), but the maximum number of colors a frame can use is 256. This limitation was reasonable when GIF was developed because hardware that could display more than 256 colors simultaneously was rare. Simple graphics, line drawings, cartoons, and grey-scale photographs typically need fewer than 256 colors.

Each frame can designate one index as a "transparent background color": any pixel assigned this index takes on the color of the pixel in the same position from the background, which may have been determined by a previous frame of animation.

Many techniques, collectively called [[dither]]ing, have been developed to approximate a wider range of colors with a small color palette by using pixels of two or more colors to approximate in-between colors. These techniques sacrifice spatial resolution to approximate deeper color resolution. While not part of the GIF specification, dithering can be used in images subsequently encoded as GIF images. This is often not an ideal solution for GIF images, both because the loss of spatial resolution typically makes an image look fuzzy on the screen, and because the dithering patterns often interfere with the compressibility of the image data, working against GIF's main purpose.

In the early days of graphical web browsers{{when|date=March 2015}}, graphics cards with 8-bit buffers (allowing only 256 colors) were common and it was fairly common to make GIF images using the [[Web-safe colors|websafe palette]].{{according_to_whom|date=March 2015}} This ensured predictable display, but severely limited the choice of colors. When 24-bit color became the norm, palettes could instead be populated with the optimum colors for individual images.

A small color table may suffice for small images, and keeping the color table small allows the file to be downloaded faster. Both the 87a and 89a specifications allow color tables of 2<sup>''n''</sup> colors for any ''n'' from 1 through 8. Most graphics applications will read and display GIF images with any of these table sizes; but some do not support all sizes when ''creating'' images. Tables of 2, 16, and 256 colors are widely supported.

===True color===
Although GIF is almost never used for [[color depth#True color (24-bit)|true color]] images, it is possible to do so.<ref name=aminet>{{cite web |url=http://uk.aminet.net/docs/misc/GIF24.readme |title=GIF 24 Bit (truecolor) extensions |author=Andreas Kleinert |year=2007 |access-date=23 March 2012 |archive-url=https://web.archive.org/web/20120316215949/http://uk.aminet.net/docs/misc/GIF24.readme |archive-date=16 March 2012}}</ref><ref name=philhoward>{{cite web |url=http://phil.ipal.org/tc.html |title=True-Color GIF Example |author=Philip Howard |access-date=23 March 2012 |archive-url=https://web.archive.org/web/20150222123613/http://phil.ipal.org/tc.html |archive-date=22 February 2015}}</ref> A GIF image can include multiple image blocks, each of which can have its own 256-color palette, and the blocks can be tiled to create a complete image. Alternatively, the GIF89a specification introduced the idea of a "transparent" color where each image block can include its own palette of 255 visible colors plus one transparent color. A complete image can be created by layering image blocks with the visible portion of each layer showing through the transparent portions of the layers above.
[[File:SmallFullColourGIF.gif|thumb|right|An animated GIF illustrating a technique for displaying more than the typical limit of 256 colors]]

To render a full-color image as a GIF, the original image must be broken down into smaller regions having no more than 255 or 256 different colors. Each of these regions is then stored as a separate image block with its own local palette and when the image blocks are displayed together (either by tiling or by layering partially transparent image blocks), the complete, full-color image appears. For example, breaking an image into tiles of 16 by 16 pixels (256 pixels in total) ensures that no tile has more than the local palette limit of 256 colors, although larger tiles may be used and similar colors merged resulting in some loss of color information.<ref name=aminet />

Since each image block can have its own local color table, a GIF file having many image blocks can be very large, limiting the usefulness of full-color GIFs.<ref name=philhoward /> Additionally, not all GIF rendering programs handle tiled or layered images correctly. Many rendering programs interpret tiles or layers as animation frames and display them in sequence as an animation<ref name=aminet /> with most web browsers automatically displaying the frames with a delay time of 0.1 seconds or more.<ref>{{cite web|url=http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser-compatibility|title=Nullsleep - Jeremiah Johnson - Animated GIF Minimum Frame Delay Browser Compatibility Study|access-date=26 May 2015|archive-date=10 October 2014|archive-url=https://web.archive.org/web/20141010173918/http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser-compatibility|url-status=live}}</ref><ref>{{cite web|url=http://blog.fenrir-inc.com/us/2012/02/theyre-different-how-to-match-the-animation-rate-of-gif-files-accross-browsers.html|archive-url=https://web.archive.org/web/20170201034945/http://blog.fenrir-inc.com/us/2012/02/theyre-different-how-to-match-the-animation-rate-of-gif-files-accross-browsers.html|url-status=dead|archive-date=1 February 2017|title=They're different! How to match the animation rate of gif files {{sic|ac|cross|nolink=y}} browsers|date=14 February 2012|website=Developer's Blog|access-date=15 June 2017}}</ref>{{better source|date=March 2015}}

==Example GIF file==
{| class="wikitable"
|-
|[[Microsoft Paint]] saves a small black-and-white image as the following GIF file (illustrated enlarged).<br/>Paint does not make optimal use of GIF; due to the unnecessarily large color table (storing a full 256 colors instead of the used 2) and symbol width, this GIF file is not an efficient representation of the 15-pixel image.<br/>Although the Graphic Control Extension block declares color index 16 (hexadecimal 10) to be transparent, that index is not used in the image. The only color indexes appearing in the image data are decimal 40 and 255, which the Global Color Table maps to black and white, respectively.
|[[File:gifSample.gif|center]]
{{small|Sample image (enlarged), actual size 3&nbsp;pixels&nbsp;wide by 5&nbsp;high}}
|}
The hex numbers in the following tables are in [[Endianness|little-endian]] byte order, as the format specification prescribes.

{| class="wikitable"
|+ Table of example GIF image values
! Byte # (hex) !! Hexadecimal !! Text or value !! colspan=2 | Meaning
|-
| 0 || 47 49 46 38 39 61 || GIF89a || colspan=2 | Header
|-
! colspan=5 | Logical Screen Descriptor
|-
| 6 || 03 00 || 3 || colspan=2 | Logical screen width
|-
| 8 || 05 00 || 5 || colspan=2 | Logical screen height
|-
| A || F7 || || colspan=2 | GCT follows for 256 colors with resolution 3{{resx}}8 bits/primary, the lowest 3 bits represent the bit depth minus 1, the highest true bit means that the GCT is present
|-
| B || 00 || 0 || colspan=2 | Background color: index #0; #000000 black
|-
| C || 00 || 0 || colspan=2 | Default pixel aspect ratio, 0:0
|-
! colspan=5 | Global Color Table
|- 
| D || 00 00 00 || 
{| class="wikitable"
! R (red) !! G (green) !! B (blue)
|-
| 0 || 0 || 0
|}
|| Global Color Table, color #0: #000000, black || rowspan=4 width=220px | [[File:GIFPAL.png|none|thumb|Bytes D<sub>h</sub> to 30C<sub>h</sub> in the example define a palette of 256 colors. The indexes used in the sample image for black and white are 28<sub>h</sub> and FF<sub>h</sub>.]]
|-
| 10 || 80 00 00 || 
{| class="wikitable"
! R (red) !! G (green) !! B (blue)
|-
| 128 || 0 || 0
|}
|| Global Color Table, color #1: transparent bit, not used in image
|-
| ... || ... || ... || Global Color Table extends to 30A
|-
| 30A || FF FF FF ||
{| class="wikitable"
! R (red) !! G (green) !! B (blue)
|-
| 255 || 255 || 255
|}
|| Global Color Table, color #255: #ffffff, white
|-
! colspan=5 | Graphic Control Extension
|-
| 30D || 21 || <code>'!'</code> || colspan="2" | An Extension Block (introduced by an ASCII exclaimation point <code>'!'</code>)
|-
| 30E || F9 || || colspan="2" | A Graphic Control Extension
|-
| 30F || 04 || 4 || colspan=2 | Amount of GCE data, 4 bytes
|-
| 310 || 01 || || colspan=2 | Transparent background color; this is a bit field, the lowest bit signifies transparency
|-
| 311 || 00 00 || || colspan=2 | Delay for animation in hundredths of a second; '''not used'''
|-
| 313 || 10 || 16 || colspan=2 | Color number of transparent pixel in GCT
|-
| 314 || 00 || || colspan=2 | End of GCE block
|-
! colspan=5 | Image Descriptor
|-
| 315 || 2C || <code>','</code>|| colspan="2" | An Image Descriptor (introduced by 0x2C, an ASCII comma <code>','</code>)
|-
| 316 || 00 00 00 00 || (0, 0) || colspan=2 | North-west corner position of image in logical screen
|-
| 31A || 03 00 05 00 || (3, 5) || colspan=2 | Image width and height in pixels
|-
| 31E || 00 || 0 || colspan=2 | Local color table bit, 0 means none
|-
! colspan=5 | Image Data
|-
| 31F || 08 || 8 || colspan=2 | Start of image, LZW minimum code size
|-
| 320 || 0B || 11 || colspan=2 | Beginning of first data sub-block, specifying 11 bytes of encoded data to follow
|-
| 321 || 00 51 FC 1B 28 70 A0 C1 83 01 01 || <image data> || colspan=2 | 11 bytes of image data, see field 320
|-
| 32C || 00 || 0 || colspan=2 | Ending data sub-block, specifying no following data bytes (and the end of the image)
|-
! colspan=5 | Trailer
|-
| 32D || 3B || <code>';'</code> || colspan=2 | File termination block indicator (an ASCII semi-colon <code>';'</code>)
|}

===Image coding===
The image pixel data, scanned horizontally from top left, are converted by [[Lempel–Ziv–Welch|LZW encoding]] to codes that are then mapped into bytes for storing in the file. The pixel codes typically don't match the 8-bit size of the bytes, so the codes are packed into bytes by a "little-Endian" scheme: the least significant bit of the first code is stored in the least significant bit of the first byte, higher order bits of the code into higher order bits of the byte, spilling over into the low order bits of the next byte as necessary. Each subsequent code is stored starting at the least significant bit not already used.

This byte stream is stored in the file as a series of "sub-blocks". Each sub-block has a maximum length 255 bytes and is prefixed with a byte indicating the number of data bytes in the sub-block. The series of sub-blocks is terminated by an empty sub-block (a single 0 byte, indicating a sub-block with 0 data bytes).

For the sample image above the reversible mapping between 9-bit codes and bytes is shown below.

{| class="wikitable" style="text-align:right;"
|+ Reversible mapping
! colspan=2 | 9-bit code
! colspan=2 | Byte
|-
! Hexadecimal !! Binary !! Binary !! Hexadecimal
|- style="font-family:monospace;"
| {{color|red|100}}   || {{color|red|1 00000000}}   || {{color|red|00000000}} || 00
|- style="font-family:monospace;"
| {{color|green|028}} || {{color|green|00 0101000}} || {{color|green|0101000}} {{color|red|1}} || 51
|- style="font-family:monospace;"
| {{color|blue|0FF}}  || {{color|blue|011 111111}}  || {{color|blue|111111}} {{color|green|00}} || FC
|- style="font-family:monospace;"
| {{color|red|103}}   || {{color|red|1000 00011}}   || {{color|red|00011}} {{color|blue|011}} || 1B
|- style="font-family:monospace;"
| {{color|green|102}} || {{color|green|10000 0010}} || {{color|green|0010}} {{color|red|1000}} || 28
|- style="font-family:monospace;"
| {{color|blue|103}}  || {{color|blue|100000 011}}  || {{color|blue|011}} {{color|green|10000}} || 70
|- style="font-family:monospace;"
| {{color|red|106}}   || {{color|red|1000001 10}}   || {{color|red|10}} {{color|blue|100000}} || A0
|- style="font-family:monospace;"
| {{color|green|107}} || {{color|green|10000011 1}} || {{color|green|1}} {{color|red|1000001}} || C1
|- style="font-family:monospace;"
|                     ||                            || {{color|green|10000011}} || 83
|- style="font-family:monospace;"
| {{color|blue|101}}  || {{color|blue|1 00000001}}  || {{color|blue|00000001}} || 01
|- style="font-family:monospace;"
|                     ||                            || {{color|black|0000000}} {{color|blue|1}} || 01
|}

A slight compression is evident: pixel colors defined initially by 15 bytes are exactly represented by 12 code bytes including control codes.
The encoding process that produces the 9-bit codes is shown below. A local string accumulates pixel color numbers from the palette, with no output action as long as the local string can be found in a code table. There is special treatment of the first two pixels that arrive before the table grows from its initial size by additions of strings. After each output code, the local string is initialized to the latest pixel color (that could not be included in the output code).

                           '''Table           9-bit'''
                      <u>'''string --> code      code    Action'''</u>
                           #0 | 000h               Initialize root table of 9-bit codes
                     palette  |  :
                      colors  |  :
                         #255 | 0FFh
                          clr | 100h
                          end | 101h
                              |            100h     Clear
 Pixel          Local         |
 color Palette  string        |
 BLACK  #40     28            |            028h     1st pixel always to output
 WHITE  #255    FF            |                     String found in table
                   28 FF      | 102h                Always add 1st string to table
                FF            |                     Initialize local string
 WHITE  #255    FF FF         |                     String not found in table
                              |            0FFh     - output code for previous string
                   FF FF      | 103h                - add latest string to table
                FF            |                     - initialize local string
 WHITE  #255    FF FF         |                     String found in table
 BLACK  #40     FF FF 28      |                     String not found in table
                              |            103h     - output code for previous string
                   FF FF 28   | 104h                - add latest string to table
                28            |                     - initialize local string
 WHITE  #255    28 FF         |                     String found in table
 WHITE  #255    28 FF FF      |                     String not found in table
                              |            102h     - output code for previous string
                   28 FF FF   | 105h                - add latest string to table
                FF            |                     - initialize local string
 WHITE  #255    FF FF         |                     String found in table
 WHITE  #255    FF FF FF      |                     String not found in table
                              |            103h     - output code for previous string
                   FF FF FF   | 106h                - add latest string to table
                FF            |                     - initialize local string
 WHITE  #255    FF FF         |                     String found in table
 WHITE  #255    FF FF FF      |                     String found in table
 WHITE  #255    FF FF FF FF   |                     String not found in table
                              |            106h     - output code for previous string
                   FF FF FF FF| 107h                - add latest string to table
                FF            |                     - initialize local string
 WHITE  #255    FF FF         |                     String found in table
 WHITE  #255    FF FF FF      |                     String found in table
 WHITE  #255    FF FF FF FF   |                     String found in table
                                                    No more pixels
                                           107h     - output code for last string
                                           101h     End

For clarity the table is shown above as being built of strings of increasing length. That scheme can function but the table consumes an unpredictable amount of memory. Memory can be saved in practice by noting that each new string to be stored consists of a previously stored string augmented by one character. It is economical to store at each address only two words: an existing address and one character.

The LZW algorithm requires a search of the table for each pixel. A linear search through up to 4096 addresses would make the coding slow. In practice the codes can be stored in order of numerical value; this allows each search to be done by a SAR (Successive Approximation Register, as used in some [[Successive approximation ADC|ADCs]]), with only 12 magnitude comparisons. For this efficiency an extra table is needed to convert between codes and actual memory addresses; the extra table upkeeping is needed only when a new code is stored which happens at much less than pixel rate.

===Image decoding===
Decoding begins by mapping the stored bytes back to 9-bit codes. These are decoded to recover the pixel colors as shown below. A table identical to the one used in the encoder is built by adding strings by this rule:
{| class="wikitable"
|+ Is incoming code found in table?
|  {{Yes}} || add string for local code followed by first byte of string for incoming code
|-
|  {{No}}  || add string for local code followed by copy of its own first byte
|}

       '''shift'''
 '''9-bit ----> Local      Table                 Pixel'''
 <u>'''code        code   code --> string   Palette color  Action'''</u>
 100h               000h  | #0                       Initialize root table of 9-bit codes
                     :    | palette
                     :    | colors
                    0FFh  | #255
                    100h  | clr
                    101h  | end
 028h                     |             #40   {{font color|WHITE|BLACK|BLACK}}  Decode 1st pixel
 0FFh        028h         |                           Incoming code found in table
                          |             #255  {{font color|BLACK|WHITE|WHITE}}   - output string from table
                    102h  | 28 FF                     - add to table
 103h        0FFh         |                           Incoming code not found in table
                    103h  | FF FF                     - add to table
                          |                           - output string from table
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
 102h        103h         |                           Incoming code found in table
                          |                           - output string from table
                          |             #40   {{font color|WHITE|BLACK|BLACK}}
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
                    104h  | FF FF 28                  - add to table
 103h        102h         |                           Incoming code found in table
                          |                           - output string from table
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
                    105h  | 28 FF FF                  - add to table
 106h        103h         |                           Incoming code not found in table
                    106h  | FF FF FF                  - add to table
                          |                           - output string from table
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
 107h        106h         |                           Incoming code not found in table
                    107h  | FF FF FF FF               - add to table
                          |                           - output string from table
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
                          |             #255  {{font color|BLACK|WHITE|WHITE}}
 101h                     |                           End

===LZW code lengths===
Shorter code lengths can be used for palettes smaller than the 256 colors in the example. If the palette is only 64 colors (so color indexes are 6 bits wide), the symbols can range from 0 to 63, and the symbol width can be taken to be 6 bits, with codes starting at 7 bits. In fact, the symbol width need not match the palette size: as long as the values decoded are always less than the number of colors in the palette, the symbols can be any width from 2 to 8, and the palette size any power of 2 from 2 to 256. For example, if only the first four colors (values 0 to 3) of the palette are used, the symbols can be taken to be 2 bits wide with codes starting at 3 bits.

Conversely, the symbol width could be set at 8, even if only values 0 and 1 are used; these data would only require a two-color table. Although there would be no point in encoding the file that way, something similar typically happens for bi-color images: the minimum symbol width is 2, even if only values 0 and 1 are used.

The code table initially contains codes that are one bit longer than the symbol size in order to accommodate the two special codes ''clr'' and ''end'' and codes for strings that are added during the process. When the table is full the code length increases to give space for more strings, up to a maximum code 4095 = FFF(hex). As the decoder builds its table it tracks these increases in code length and it is able to unpack incoming bytes accordingly.

===Uncompressed GIF ===
{| class="wikitable floatright" width=145px
|-
|[[File:Quilt design as 46x46 uncompressed GIF.gif|center]]
{{small|A 46×46 uncompressed GIF with 7-bit symbols (128 colors, 8-bit codes).<br/>Click on the image for an explanation of the code.}}
|}
The GIF encoding process can be modified to create a file without LZW compression that is still viewable as a GIF image. This technique was introduced originally as a way to avoid patent infringement. Uncompressed GIF can also be a useful intermediate format for a graphics programmer because individual pixels are accessible for reading or painting. An uncompressed GIF file can be converted to an ordinary GIF file simply by passing it through an image editor.

The modified encoding method ignores building the LZW table and emits only the root palette codes and the codes for CLEAR and STOP. This yields a simpler encoding (a 1-to-1 correspondence between code values and palette codes) but sacrifices all of the compression: each pixel in the image generates an output code indicating its color index. When processing an uncompressed GIF, a standard GIF decoder will not be prevented from writing strings to its dictionary table, but the code width must never increase since that triggers a different packing of bits to bytes.

If the symbol width is {{mvar|n}}, the codes of width {{math|''n''+1}} fall naturally into two blocks: the lower block of {{math|2{{sup|''n''}}}} codes for coding single symbols, and the upper block of {{math|2{{sup|''n''}}}} codes that will be used by the decoder for sequences of length greater than one. Of that upper block, the first two codes are already taken: {{math|2{{sup|''n''}}}} for CLEAR and {{math|2{{sup|''n''}} + 1}} for STOP. The decoder must also be prevented from using the last code in the upper block, {{math|2<sup>''n''+1</sup> − 1}}, because when the decoder fills that slot, it will increase the code width. Thus in the upper block there are {{math|2{{sup|''n''}} − 3}} codes available to the decoder that won't trigger an increase in code width. Because the decoder is always one step behind in maintaining the table, it does not generate a table entry upon receiving the first code from the encoder, but will generate one for each succeeding code. Thus the encoder can generate {{math|2{{sup|''n''}} − 2}} codes without triggering an increase in code width. Therefore, the encoder must emit extra CLEAR codes at intervals of {{math|2{{sup|''n''}} − 2}} codes or less to make the decoder reset the coding dictionary. The GIF standard allows such extra CLEAR codes to be inserted in the image data at any time. The composite data stream is partitioned into sub-blocks that each carry from 1 to 255 bytes.

For the sample 3×5 image above, the following 9-bit codes represent "clear" (100) followed by image pixels in scan order and "stop" (101).

 100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101

After the above codes are mapped to bytes, the uncompressed file differs from the compressed file thus:

{| class="wikitable"
! Byte # (hex) !! Hexadecimal !! Text or value !! Meaning 
|-
| 320 || 14 || 20 || 20 bytes uncompressed image data follow
|-
| 321 || 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01 || ||
|-
| 335 || 00 || 0 || End of image data
|}

==Compression example==
The trivial example of a large image of solid color demonstrates the variable-length LZW compression used in GIF files.
{| class="wikitable"
|+Sample compression of a GIF file
|-
! scope="col" colspan=3 | Code
! scope="col" colspan=2 | Pixels
!scope="col" | Notes
|-
!scope="col" | No.{{pb}}N{{sub|i}}
!scope="col" | Value{{pb}}N{{sub|i}} + 256
!scope="col" | Length{{pb}}(bits)
!scope="col" | This code{{pb}}N{{sub|i}}
!scope="col" | Accumulated{{pb}}{{sfrac|N{{sub|i}}(N{{sub|i}} + 1)|2}}
| Relations using N{{sub|i}} only apply to same-color pixels until coding table is full.
|-
| style="text-align: center;" | 0
| style="text-align: center;" | 100h
| style="text-align: center;" rowspan=4 | 9
|
|
| Clear code table
|-
| style="text-align: center;" | 1
| style="text-align: center;" | FFh
| style="text-align: center;" | 1
| style="text-align: center;" | 1
| Top left pixel color chosen as the highest index of a 256-color palette
|-
| style="text-align: center;" | 2
| style="text-align: center;" | 102h
| style="text-align: center;" | 2
| style="text-align: center;" | 3
|
|-
| style="text-align: center;" | 3{{pb}}⋮{{pb}}255
| style="text-align: center;" | 103h{{pb}}⋮{{pb}}1FFh
| style="text-align: center;" | 3{{pb}}⋮{{pb}}255
| style="text-align: center;" | 6{{pb}}⋮{{pb}}32640
| Last 9-bit code
|-
| style="text-align: center;" | 256{{pb}}⋮{{pb}}767
| style="text-align: center;" | 200h{{pb}}⋮{{pb}}3FFh
| style="text-align: center;" | 10
| style="text-align: center;" | 256{{pb}}⋮{{pb}}767
| style="text-align: center;" | 32896{{pb}}⋮{{pb}}294528
| Last 10-bit code
|-
| style="text-align: center;" | 768{{pb}}⋮{{pb}}1791
| style="text-align: center;" | 400h{{pb}}⋮{{pb}}7FFh
| style="text-align: center;" | 11
| style="text-align: center;" | 768{{pb}}⋮{{pb}}1791
| style="text-align: center;" | 295296{{pb}}⋮{{pb}}1604736
| Last 11-bit code
|-
| style="text-align: center;" | 1792{{pb}}⋮{{pb}}3839
| style="text-align: center;" | 800h{{pb}}⋮{{pb}}FFFh
| style="text-align: center;" rowspan=3 | 12
| style="text-align: center;" | 1792{{pb}}⋮{{pb}}3839
| style="text-align: center;" | 1606528{{pb}}⋮{{pb}}7370880
| Code table full
|-
| style="text-align: center;" | ⋮
| style="text-align: center;" | FFFh
| style="text-align: center;" | 3839
| colspan=2 | The maximum code may repeat for more same-color pixels.{{pb}}Overall data compression asymptotically approaches 3839 × {{sfrac|8|12}} = {{sfrac|2559|1|3}}
|-
|
| style="text-align: center;" | 101h
|
|
| End of image data
|}
The code values shown are packed into bytes which are then packed into blocks of up to 255 bytes. A block of image data begins with a byte that declares the number of bytes to follow. The last block of data for an image is marked by a zero block-length byte.

== Interlacing ==
[[File:Interlaced GIF demo.gif|thumb|upright|Screen capture of an interlaced GIF loading in a web browser]]
The GIF Specification allows each image within the logical screen of a GIF file to specify that it is interlaced; i.e., that the order of the raster lines in its data block is not sequential. This allows a partial display of the image that can be recognized before the full image is painted.

An interlaced image is divided from top to bottom into strips 8 pixels high, and the rows of the image are presented in the following order:
* Pass 1: Line 0 (the top-most line) from each strip.
* Pass 2: Line 4 from each strip.
* Pass 3: Lines 2 and 6 from each strip.
* Pass 4: Lines 1, 3, 5, and 7 from each strip.

The pixels within each line are not interlaced, but presented consecutively from left to right. As with non-interlaced images, there is no break between the data for one line and the data for the next. The indicator that an image is interlaced is a bit set in the corresponding Image Descriptor block.

==Animated GIF==

[[File:Newtons cradle animation book 2.gif|thumb|left|GIF can be used to display animation, as in this image of [[Newton's cradle]].]]
Although GIF was not designed as an animation medium, its ability to store multiple images in one file naturally suggested using the format to store the [[Film frame|frames]] of an animation sequence. To facilitate ''displaying'' animations, the GIF89a spec added the Graphic Control Extension (GCE), which allows the images (frames) in the file to be painted with time delays, forming a [[video clip]]. Each frame in an animation GIF is introduced by its own GCE specifying the time delay to wait after the frame is drawn. Global information at the start of the file applies by default to all frames. The data is stream-oriented, so the file offset of the start of each GCE depends on the length of preceding data. Within each frame the LZW-coded image data is arranged in sub-blocks of up to 255 bytes; the size of each sub-block is declared by the byte that precedes it.

By default, an animation displays the sequence of frames only once, stopping when the last frame is displayed. To enable an animation to loop, [[Netscape]] in the 1990s used the Application Extension block (intended to allow vendors to add application-specific information to the GIF file) to implement the Netscape Application Block (NAB).<ref>{{cite web
 |url=http://www6.uniovi.es/gifanim/gifabout.htm
 |title=All About GIF89a
 |author=Royal Frazier
 |access-date=7 January 2013
 |archive-url=https://web.archive.org/web/19990418091037/http://www6.uniovi.es/gifanim/gifabout.htm
 |archive-date=18 April 1999
 |url-status=dead
 }}</ref> This block, placed immediately before the sequence of animation frames, specifies the number of times the sequence of frames should be played (1 to 65535 times) or that it should repeat continuously (zero indicates loop forever). Support for these repeating animations first appeared in [[Netscape Navigator]] version 2.0, and then spread to other browsers.<ref>
{{cite book |isbn=0-7897-0947-3
 |title=Web Scripting Secret Weapons
 |author=Scott Walter |publisher=[[Que Publishing]] |year=1996
}}</ref> Most browsers now recognize and support NAB, though it is not strictly part of the GIF89a specification.

The following example shows the structure of the animation file ''[[:File:Rotating earth (large).gif|Rotating earth (large).gif]]'' shown (as a thumbnail) in the article's infobox.<!-- Given for the last file version (27 August 2019) -->

{| class="wikitable"
|+ Structure of GIF
! Byte # (hex) !! Hexadecimal || Text or value || Meaning
|-
| 0 || 47 49 46 38 39 61 || GIF89a || Logical Screen Descriptor
|-
| 6 || 90 01 || 400 || Width in pixels
|-
| 8 || 90 01 || 400 || Height in pixels
|-
| A || F7 || || GCT follows for 256 colors with resolution 3{{resx}}8 bits/primary
|-
| B || 00 || 0 || Background color: #000000, black
|-
| C || 00 || 0 || Default pixel aspect ratio, 0:0
|-
| D || 00 || || Global Color Table
|-
| ⋮ || || ||
|-
|30D
|21
|<code>'!'</code>
|An Extension Block (introduced by an ASCII exclaimation point <code>'!'</code>)
|-
| 30E || FF || || Application Extension
|-
| 30F || 0B || 11 || Size of block including application name and verification bytes (always 11)
|-
| 310 || 4E 45 54 53 43 41 50 45 32 2E 30 || NETSCAPE2.0 || 8-byte application name plus 3 verification bytes
|-
| 31B || 03 || 3 || Number of bytes in the following sub-block
|-
| 31C || 01 || 1 || Index of the current data sub-block ''(always 1 for the NETSCAPE block)'' 
|-
| 31D || FF FF || 65535 || [[Unsigned number]] of repetitions
|-
| 31F || 00 || || End of the sub-block chain for the Application Extension block
|-
|320
|21
|<code>'!'</code>
|An Extension Block (introduced by an ASCII exclaimation point <code>'!'</code>)
|-
| 321 || F9 || || Graphic Control Extension for frame #1
|-
| 322 || 04 || 4 || Number of bytes (4) in the current sub-block
|-
| 323 || 04 || <syntaxhighlight lang="text">
000.....
...001..
......0.
.......0
</syntaxhighlight> ''(broken into sections for easier reading)'' || Reserved, 5 lower bits are [[bit field]]<br/>Disposal method 1: do not dispose<br/>No user input<br/>Transparent color, 0 means not given
|-
| 324 || 09 00 || 9 || Frame delay: 0.09 second delay before painting next frame
|-
| 326 || FF || || Transparent color index ''(unused in this frame)''
|-
| 327 || 00 || || End of sub-block chain for Graphic Control Extension block
|-
| 328 || 2C || <code>','</code>|| An Image Descriptor (introduced by 0x2C, an ASCII comma <code>','</code>)
|-
| 329 || 00 00 00 00 || (0, 0) || North-west corner position of image in logical screen: (0, 0)
|-
| 32D || 90 01 90 01 || (400, 400) || Frame width and height: 400{{resx}}400 pixels
|-
| 331 || 00 || 0 || Local color table: 0 means none & no interlacing
|-
| 332 || 08 || 8 || Minimum LZW code size for Image Data of frame #1
|-
| 333 || FF || 255 || Number of bytes of LZW image data in the following sub-block: 255 bytes
|-
| 334 || ... || <image data> || Image data, 255 bytes
|-
| 433 || FF || 255 || Number of bytes of LZW image data in the following sub-block, 255 bytes
|-
| 434 || ... || <image data> || Image data, 255 bytes
|-
| ⋮ || || || Repeat for next blocks
|-
| 92C0 || 00 || || End of sub-block chain for this frame
|-
|92C1
|21
|<code>'!'</code>
|An Extension Block (introduced by an ASCII exclaimation point <code>'!'</code>)
|-
| 92C2 || F9 || || Graphic Control Extension for frame #2
|-
| ⋮ || || || Repeat for next frames
|-
|EDABD
|21
|<code>'!'</code>
|An Extension Block (introduced by an ASCII exclaimation point <code>'!'</code>)
|-
| EDABE || F9 || || Graphic Control Extension for frame #44
|-
| ⋮ || || || Image information and data for frame #44
|-
| F48F5 || 3B || || Trailer: Last byte in the file, signaling EOF
|}

The animation delay for each frame is specified in the GCE in hundredths of a second. Some economy of data is possible where a frame need only rewrite a portion of the pixels of the display, because the Image Descriptor can define a smaller rectangle to be rescanned instead of the whole image. Browsers or other displays that do not support animated GIFs typically show only the first frame.

The size and color quality of animated GIF files can vary significantly depending on the application used to create them. Strategies for minimizing file size include using a common global color table for all frames (rather than a complete local color table for each frame) and minimizing the number of pixels covered in successive frames (so that only the pixels that change from one frame to the next are included in the latter frame). More advanced techniques involve modifying color sequences to better match the existing LZW dictionary, a form of [[lossy compression]]. Simply packing a series of independent frame images into a composite animation tends to yield large file sizes. Tools are available to minimize the file size given an existing GIF.

== Metadata ==
[[Metadata]] can be stored in GIF files as a comment block, a plain text block, or an application-specific application extension block.  Several graphics editors use unofficial application extension blocks to include the data used to generate the image, so that it can be recovered for further editing.

All of these methods technically require the metadata to be broken into sub-blocks so that applications can navigate the metadata block without knowing its internal structure.

The [[Extensible Metadata Platform]] (XMP) metadata standard introduced an unofficial but now widespread "XMP Data" application extension block for including XMP data in GIF files.<ref>{{cite web |url=https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart3.pdf |title=XMP Specification Part 3: Storage in Files |date=2016 |publisher=Adobe |pages=11–12 |access-date=16 August 2018 |archive-date=25 February 2018 |archive-url=https://web.archive.org/web/20180225154501/https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart3.pdf |url-status=live }}</ref> Since the XMP data is encoded using [[UTF-8]] without NUL characters, there are no 0 bytes in the data. Rather than break the data into formal sub-blocks, the extension block terminates with a "magic trailer" that routes any application treating the data as sub-blocks to a final 0 byte that terminates the sub-block chain.

== Unisys and LZW patent enforcement ==<!-- This section is linked from PNG -->
In 1977 and 1978, [[Jacob Ziv]] and [[Abraham Lempel]] published a pair of papers on a new class of lossless data-compression algorithms, now collectively referred to as [[LZ77 and LZ78]]. In 1983, [[Terry Welch]] developed a fast variant of LZ78 which was named [[Lempel–Ziv–Welch]] (LZW).<ref name="PNG">{{cite web
 |url=http://www.libpng.org/pub/png/pnghist.html
 |title=History of the Portable Network Graphics (PNG) Format
 |author=Greg Roelofs
 |access-date=23 March 2012
 |archive-date=7 March 2012
 |archive-url=https://web.archive.org/web/20120307042624/http://www.libpng.org/pub/png/pnghist.html
 |url-status=live
 }}</ref><ref name="KYZ">{{cite web
 |url=http://www.kyzer.me.uk/essays/giflzw/
 |title=Sad day... GIF patent dead at 20
 |author=Stuart Caie
 |access-date=23 March 2012
 |archive-date=10 February 2012
 |archive-url=https://web.archive.org/web/20120210060008/http://www.kyzer.me.uk/essays/giflzw/
 |url-status=live
 }}</ref>

Welch filed a patent application for the LZW method in June 1983. The resulting patent, US4558302,<ref>{{Cite patent|country=US|number=4558302|inventor-last=Welch|inventor-first=Terry A.|assign=[[Sperry Corp.]]|pubdate=1985-12-10|inventor1-link=Terry_Welch}}</ref> granted in December 1985, was assigned to [[Sperry Corporation]] who subsequently merged with [[Burroughs Corporation]] in 1986 and formed [[Unisys]].<ref name="PNG" /> Further patents were obtained in the United Kingdom, France, Germany, Italy, Japan and Canada.

In addition to the above patents, Welch's 1983 patent also includes citations to several other patents that influenced it, including:
* two 1980 Japanese patents from [[NEC]]'s Jun Kanatsu,<ref>{{cite patent
| country	= JP
| number	= S5719857A
| status	= patent
| title		= Data compression storage device
| pubdate	= 1982-02-02
| fdate		= 1980-07-09
| inventor1-last	= Kanatsu
| inventor1-first	= Jiyun
| assign1	= [[Nippon_Electric_Corporation|Nippon Electric Corp.]]
}}</ref><ref>{{cite patent
| country	= JP
| number	= S57101937A
| status	= patent
| title		= Data storage device
| pubdate	= 1986-20-24
| fdate		= 1980-12-16
| inventor1-last	= Kanatsu
| inventor1-first	= Jiyun
| assign1	= [[Nippon_Electric_Corporation|Nippon Electric Corp.]]
}}</ref>
* {{US patent|4021782}} (1974) from John S. Hoerning,
* {{US patent|4366551}} (1977) from Klaus E. Holtz, and
* a 1981 German patent from Karl Eckhart Heinz.<ref>{{cite patent
| country	= DE
| number	= 3118676
| status	= patent
| title		= Verfahren zur Kompression redundanter Folgen serieller Datenelemente [Method for compressing redundant sequences of serial data elements]
| pubdate	= 1982-12-02
| fdate		= 1981-05-12
| inventor1-last	= Eckhart
| inventor1-first	= Heinz Karl
}}</ref><ref>{{US patent|4558302}}</ref>

In June 1984, an article by Welch was published in the [[IEEE]] magazine which publicly described the LZW technique for the first time.<ref name="cloanto">{{cite web|url=https://mike.pub/19950127-gif-lzw|title=The GIF Controversy: A Software Developer's Perspective|date=27 January 1995 |access-date=26 May 2015|archive-date=23 August 2016|archive-url=https://web.archive.org/web/20160823024419/https://mike.pub/19950127-gif-lzw|url-status=live}}</ref> LZW became a popular data compression technique and, when the patent was granted, Unisys entered into licensing agreements with over a hundred companies.<ref name="PNG" /><ref name="LPF">{{cite web|url=https://www.thefreelibrary.com/UNISYS+CLARIFIES+POLICY+REGARDING+PATENT+USE+IN+ON-LINE+SERVICE+...-a016000999 |title=Unisys Clarifies Policy Regarding Patent Use in On-Line Service Offerings |archive-url=https://web.archive.org/web/20070207110047/http://lpf.ai.mit.edu/Patents/Gif/unisys.html|archive-date=7 February 2007}} – archived by [[League for Programming Freedom]]</ref>

The popularity of LZW led [[CompuServe]] to choose it as the compression technique for their version of GIF, developed in 1987. At the time, CompuServe was not aware of the patent.<ref name="PNG" /> Unisys became aware that the version of GIF used the LZW compression technique and entered into licensing negotiations with CompuServe in January 1993. The subsequent agreement was announced on 24 December 1994.<ref name="KYZ" /> Unisys stated that they expected all major commercial on-line information services companies employing the LZW patent to license the technology from Unisys at a reasonable rate, but that they would not require licensing, or fees to be paid, for non-commercial, non-profit GIF-based applications, including those for use on the on-line services.<ref name="LPF" />

Following this announcement, there was widespread condemnation of CompuServe and Unisys, and many software developers threatened to stop using GIF. The [[Portable Network Graphics|PNG format]] (see below) was developed in 1995 as an intended replacement.<ref name="PNG" /><ref name="KYZ" /><ref name="cloanto" /> However, obtaining support from the makers of Web browsers and other software for the PNG format proved difficult and it was not possible to replace GIF, although PNG has gradually increased in popularity.<ref name="PNG" /> Therefore, GIF variations without LZW compression were developed. For instance the libungif library, based on [[Eric S. Raymond]]'s giflib, allows creation of GIFs that followed the data format but avoided the compression features, thus avoiding use of the Unisys LZW patent.<ref>{{cite web|url=https://directory.fsf.org/wiki/Libungif|title=Libungif|access-date=26 May 2015|archive-date=13 April 2015|archive-url=https://web.archive.org/web/20150413095700/http://directory.fsf.org/wiki/Libungif|url-status=live}}</ref> A 2001 ''[[Dr. Dobb's Journal|Dr. Dobb's]]'' article described a way to achieve LZW-compatible encoding without infringing on its patents.<ref>{{cite web |url=http://www.drdobbs.com/architecture-and-design/replacing-a-dictionary-with-a-square-roo/184404817 |title=Replacing a Dictionary with a Square Root |work=[[Dr. Dobb's Journal]] |first=Tom |last=Cargill |date=2001-10-01 |access-date=2017-01-20 |archive-date=28 June 2017 |archive-url=https://web.archive.org/web/20170628173622/http://www.drdobbs.com/architecture-and-design/replacing-a-dictionary-with-a-square-roo/184404817 |url-status=live }}</ref>

In August 1999, Unisys changed the details of their licensing practice, announcing the option for owners of certain non-commercial and private websites to obtain licenses on payment of a one-time license fee of $5000 or $7500.<ref name="Unisys">{{cite web|url=http://www.unisys.com/about__unisys/lzw/lzw__license__english.htm |title=LZW Software and Patent Information |access-date=2007-01-31 |url-status=dead |archive-url=https://web.archive.org/web/20090608194513/http://www.unisys.com/about__unisys/lzw/lzw__license__english.htm |archive-date=8 June 2009 }} – clarification of 2 September 1999</ref> Such licenses were not required for website owners or other GIF users who had used licensed software to generate GIFs. Nevertheless, Unisys was subjected to thousands of online attacks and abusive emails from users believing that they were going to be charged $5000 or sued for using GIFs on their websites.<ref name="slashdot">[https://slashdot.org/story/99/08/31/0143246/unisys-not-suing-most-webmasters-for-using-gifs Unisys Not Suing (most) Webmasters for Using GIFs] {{Webarchive|url=https://web.archive.org/web/20170510024223/https://slashdot.org/story/99/08/31/0143246/unisys-not-suing-most-webmasters-for-using-gifs |date=10 May 2017 }} – [[Slashdot]] investigation into the controversy</ref> Despite giving free licenses to hundreds of non-profit organizations, schools and governments, Unisys was completely unable to generate any good publicity and continued to be condemned by individuals and organizations such as the [[League for Programming Freedom]] who started the "Burn All GIFs" campaign in 1999.<ref>{{cite web|archive-url=https://web.archive.org/web/19991013083423/http://burnallgifs.org/ |archive-date=1999-10-13 |url=http://burnallgifs.org/ |title=Burn All GIFs Day}}</ref><ref name="burn">[http://burnallgifs.org/archives/ Burn All GIFs] {{Webarchive|url=https://web.archive.org/web/20070203044403/http://burnallgifs.org/archives/ |date=3 February 2007 }} – A project of the League for Programming Freedom (latest version)</ref>

The United States LZW patent expired on 20 June 2003.<ref name="Unisys2"/> The counterpart patents in the United Kingdom, France, Germany and Italy expired on 18 June 2004, the Japanese patents expired on 20 June 2004, and the Canadian patent expired on 7 July 2004.<ref name="Unisys2">{{cite web|url=http://www.unisys.com/about__unisys/lzw |title=License Information on GIF and Other LZW-based Technologies |access-date=2005-04-26 |url-status=dead |archive-url=https://web.archive.org/web/20090602212118/http://www.unisys.com/about__unisys/lzw |archive-date=2 June 2009 }}</ref> Consequently, while Unisys has further patents and patent applications relating to improvements to the LZW technique,<ref name="Unisys2" /> LZW itself (and consequently GIF) have been free to use since July 2004.<ref>{{cite web |url=https://www.gnu.org/philosophy/gif.html |title=Why There Are No GIF Files on GNU Web Pages |publisher=Free Software Foundation |access-date=19 May 2012 |archive-date=19 May 2012 |archive-url=https://web.archive.org/web/20120519232602/http://www.gnu.org/philosophy/gif.html |url-status=live }}</ref>

==Alternatives==

===PNG===
[[Portable Network Graphics]] (PNG) was designed as a replacement for GIF in order to avoid infringement of Unisys' patent on the LZW compression technique.<ref name="PNG" /> PNG offers better compression and more features than GIF,<ref name="png_fea">{{cite web |title=PNG versus GIF Compression |date=31 March 2007 |url=http://www.websiteoptimization.com/speed/tweak/png/ |access-date=8 June 2009 |url-status=live |archive-url=https://web.archive.org/web/20090715080828/http://www.websiteoptimization.com/speed/tweak/png/ |archive-date=15 July 2009}}</ref> animation being the only significant exception. PNG is more suitable than GIF in instances where true-color imaging and [[alpha transparency]] are required.

Although support for PNG format came slowly, new [[web browser]]s support PNG. Older versions of [[Internet Explorer]] do not support all features of PNG. Versions 6 and earlier do not support [[alpha channel]] transparency without using Microsoft-specific HTML extensions.<ref>{{cite web |title=AlphaImageLoader Filter |date=4 September 2012 |publisher=Microsoft |url=http://msdn.microsoft.com/en-us/library/ms532969(VS.85).aspx |access-date=26 May 2015 |archive-date=3 October 2014 |archive-url=https://web.archive.org/web/20141003214847/http://msdn.microsoft.com/en-us/library/ms532969(VS.85).aspx |url-status=live}}</ref> [[gamma correction|Gamma]] correction of PNG images was not supported before version 8, and the display of these images in earlier versions may have the wrong tint.<ref name="new_ie7">{{cite web |url= http://msdn.microsoft.com/en-us/library/ms649487%28VS.85%29.aspx |title= What's New in Internet Explorer 7 |work= [[MSDN]] |access-date= 6 March 2009 |archive-date= 1 March 2009 |archive-url= https://web.archive.org/web/20090301140032/http://msdn.microsoft.com/en-us/library/ms649487(VS.85).aspx |url-status= live }}<!--<on no gamma support--></ref>

For identical 8-bit (or lower) image data, PNG files are typically smaller than the equivalent GIFs, due to the more efficient compression techniques used in PNG encoding.<ref name="png_opt">{{cite web |title=PNG Image File Format |url=http://www.scantips.com/basics9p.html |access-date= 8 June 2009 |archive-url=https://web.archive.org/web/20090614110627/http://www.scantips.com/basics9p.html |archive-date=14 June 2009 |url-status=live}}</ref> Complete support for GIF is complicated chiefly by the complex canvas structure it allows, though this is what enables the compact animation features.

===Animation formats===
Videos resolve many issues that GIFs present through common usage on the web. They include drastically smaller [[file size]]s, the ability to surpass the [[8-bit color]] restriction, and better frame-handling and compression through [[Inter frame|inter-frame coding]]. Virtually universal support for the GIF format in [[web browser]]s and a lack of official support for video in the [[HTML]] standard caused GIF to rise to prominence for the purpose of displaying short video-like files on the web.

* [[Multiple-image Network Graphics|MNG]] ("Multiple-image Network Graphics") was originally developed as a PNG-based solution for animations. MNG reached version 1.0 in 2001, but few applications support it.

* [[Animated Portable Network Graphics|APNG]] ("Animated Portable Network Graphics") was proposed by [[Mozilla]] in 2006. APNG is an extension to the PNG format as alternative to the MNG format. APNG is supported by most browsers as of 2019.<ref>{{Cite web|url=https://caniuse.com/#feat=apng|title=Can I use... Support tables for HTML5, CSS3, etc|website=caniuse.com|access-date=10 April 2020|archive-date=19 February 2018|archive-url=https://web.archive.org/web/20180219074228/https://caniuse.com/#feat=apng|url-status=live}}</ref> APNG provides the ability to animate PNG files, while retaining backwards compatibility in decoders that cannot understand the animation chunk (unlike MNG). Older decoders will simply render the first frame of the animation.

: The PNG group officially rejected APNG as an official extension on 20 April 2007.<ref>{{cite web|url=http://sourceforge.net/mailarchive/message.php?msg_id=131482|title=VOTE FAILED: APNG 20070405a|publisher=[[SourceForge]] mailing list|date=2007-04-20|access-date=14 July 2013|archive-date=13 February 2013|archive-url=https://web.archive.org/web/20130213103632/http://sourceforge.net/mailarchive/message.php?msg_id=131482|url-status=live}}</ref>

: There have been several subsequent proposals for a simple animated graphics format based on PNG using several different approaches.<ref name="proposalcomparison">{{cite web |url=http://gjuyn.xs4all.nl/pnganim.html |title=Discussion for a simple "animated" PNG format |archive-date=2009-02-26 |archive-url=https://web.archive.org/web/20090226103407/http://gjuyn.xs4all.nl/pnganim.html |access-date=2011-07-12}}</ref> Nevertheless, APNG is still under development by Mozilla and is supported in [[Mozilla Firefox#Version 3.0|Firefox 3.0]]<ref name="APNG">{{cite web|url=https://wiki.mozilla.org/APNG_Specification|title=APNG Specification|access-date=26 May 2015|archive-date=5 July 2010|archive-url=https://web.archive.org/web/20100705233055/https://wiki.mozilla.org/APNG_Specification|url-status=live}}</ref><ref name="mozlabsapng">{{Cite web |url=https://blog.mozilla.org/labs/2007/08/better-animations-in-firefox-3/ |title=Mozilla Labs » Blog Archive » Better animations in Firefox 3<!-- Bot generated title --> |date=13 August 2007 |access-date=3 February 2016 |archive-date=7 March 2016 |archive-url=https://web.archive.org/web/20160307093938/https://blog.mozilla.org/labs/2007/08/better-animations-in-firefox-3/ |url-status=live }}</ref> while MNG support was dropped.<ref>{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=195280|title=195280 – Removal of MNG/JNG support|access-date=26 May 2015|archive-date=25 February 2021|archive-url=https://web.archive.org/web/20210225102000/https://bugzilla.mozilla.org/show_bug.cgi?id=195280|url-status=live}}</ref><ref>{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=18574|title=18574 – (mng) restore support for MNG animation format and JNG image format|access-date=26 May 2015|archive-date=17 March 2021|archive-url=https://web.archive.org/web/20210317013748/https://bugzilla.mozilla.org/show_bug.cgi?id=18574|url-status=live}}</ref> APNG is currently supported by all major web browsers including Chrome (since version 59.0), Opera, Firefox and Edge.

* Embedded [[Adobe Flash]] objects and [[MPEG]] files were used on some websites to display simple video, but required the use of an additional browser plugin.

* [[WebM]] and [[WebP]] are in development and are supported by some web browsers.<ref>{{cite web |url=https://blog.chromium.org/2013/11/chrome-32-beta-animated-webp-images-and.html |title=Chromium Blog: Chrome 32 Beta: Animated WebP images and faster Chrome for Android touch input |publisher=Blog.chromium.org |date=2013-11-21 |access-date=2014-02-01 |archive-date=17 July 2018 |archive-url=https://web.archive.org/web/20180717235844/https://blog.chromium.org/2013/11/chrome-32-beta-animated-webp-images-and.html |url-status=live }}</ref>

* Other options for web animation include serving individual frames using [[AJAX]], or animating [[Scalable vector graphics|SVG]] ("Scalable vector graphics") images using [[JavaScript]] or [[Synchronized Multimedia Integration Language|SMIL]] ("Synchronized Multimedia Integration Language").<ref>{{Cite web |last=Calou |first=Juan |title=SVG Animation - A Guide |website=Toptal |url=https://www.toptal.com/front-end/svg-animation-guide |access-date=March 15, 2024}}</ref>

* With the introduction of widespread support of the [[HTML video]] (<code><video></code>) tag in most web browsers, some websites use a looped version of the video tag generated by [[JavaScript]] functions. This gives the appearance of a GIF, but with the size and speed advantages of compressed video.

: Notable examples are [[Gfycat]] and [[Imgur]] and their GIFV metaformat, which is really a video tag playing a looped [[MP4]] or [[WebM]] compressed video.<ref>{{cite web |url=http://imgur.com/blog/2014/10/09/introducing-gifv/ |title=Introducing GIFV - Imgur Blog |publisher=imgur.com |date=2014-10-09 |access-date=2014-12-14 |archive-date=14 December 2014 |archive-url=https://web.archive.org/web/20141214115941/http://imgur.com/blog/2014/10/09/introducing-gifv/ |url-status=live }}</ref>

* [[High Efficiency Image File Format|HEIF]] ("High Efficiency Image File Format") is an image file format, finalized in 2015, which uses a [[discrete cosine transform]] (DCT) [[lossy compression]] algorithm based on the [[HEVC]] video format, and related to the [[JPEG]] image format. In contrast to JPEG, HEIF supports animation.<ref>{{cite web |last1=Thomson |first1=Gavin |last2=Shah |first2=Athar |title=Introducing HEIF and HEVC |url=https://devstreaming-cdn.apple.com/videos/wwdc/2017/503i6plfvfi7o3222/503/503_introducing_heif_and_hevc.pdf |publisher=[[Apple Inc.]] |year=2017 |access-date=5 August 2019 |archive-date=19 January 2020 |archive-url=https://web.archive.org/web/20200119034339/https://devstreaming-cdn.apple.com/videos/wwdc/2017/503i6plfvfi7o3222/503/503_introducing_heif_and_hevc.pdf |url-status=live }}</ref> 

: Compared to the GIF format, which lacks DCT compression, HEIF allows significantly more efficient compression. HEIF stores more information and produces higher-quality animated images at a small fraction of an equivalent GIF's size.<ref>{{cite web |title=HEIF Comparison - High Efficiency Image File Format |url=https://nokiatech.github.io/heif/comparison.html |publisher=[[Nokia Technologies]] |access-date=5 August 2019 |archive-date=25 July 2019 |archive-url=https://web.archive.org/web/20190725135250/http://nokiatech.github.io/heif/comparison.html |url-status=live }}</ref>

* [[VP9]] only supports [[alpha compositing]] with 4:2:0 [[chroma subsampling]],<ref>{{Cite web|url=https://trac.ffmpeg.org/ticket/3271?cversion=0&cnum_hist=3|title=#3271 (Allow using additional pixel formats with libvpx-vp9) – FFmpeg|website=trac.ffmpeg.org|access-date=10 April 2020|archive-date=16 June 2020|archive-url=https://web.archive.org/web/20200616041834/https://trac.ffmpeg.org/ticket/3271?cversion=0&cnum_hist=3|url-status=live}}</ref> which may be unsuitable for GIFs that combine transparency with [[rasterisation|rasterised]] [[vector graphics]] with fine color details.

* [[AV1]] video codec or [[AVIF]] can also be used either as a video or a sequenced image.

====Uses====
In April 2014, [[4chan]] added support for silent [[WebM]] videos that are under 3 MB in size and 2 min in length,<ref>{{cite news|last1=Dewey|first1=Caitlin|title=Meet the technology that could make GIFs obsolete|url=https://www.washingtonpost.com/blogs/style-blog/wp/2014/04/08/meet-the-technology-that-could-make-gifs-obsolete/|newspaper=[[The Washington Post]]|access-date=4 February 2015|archive-date=11 May 2015|archive-url=https://web.archive.org/web/20150511102846/http://www.washingtonpost.com/blogs/style-blog/wp/2014/04/08/meet-the-technology-that-could-make-gifs-obsolete/|url-status=live}}</ref><ref>{{cite web|title=WebM support on 4chan|url=http://blog.4chan.org/post/81896300203/webm-support-on-4chan|publisher=[[4chan|4chan Blog]]|access-date=4 February 2015|archive-date=6 April 2014|archive-url=https://archive.today/20140406171238/http://blog.4chan.org/post/81896300203/webm-support-on-4chan|url-status=live}}</ref> and in October 2014, [[Imgur]] started converting any GIF files uploaded to the site to [[H.264]] video and giving the link to the HTML player the appearance of an actual file with a <code>.gifv</code> extension.<ref>{{cite web|access-date=2016-07-21|date=2014-08-09|title=Introducing GIFV|publisher=Imgur|url=http://blog.imgur.com/2014/10/09/introducing-gifv/|archive-date=5 May 2020|archive-url=https://web.archive.org/web/20200505012906/https://blog.imgur.com/2014/10/09/introducing-gifv/|url-status=live}}</ref><ref>{{cite web|last1=Allan|first1=Patrick|title=Imgur Revamps GIFs for Faster Speeds and Higher Quality with GIFV|date=9 October 2014 |url=http://lifehacker.com/imgur-revamps-gifs-for-faster-speeds-and-higher-quality-1644494212|publisher=[[Lifehacker]]|access-date=4 February 2015|archive-date=3 February 2015|archive-url=https://web.archive.org/web/20150203080613/http://lifehacker.com/imgur-revamps-gifs-for-faster-speeds-and-higher-quality-1644494212|url-status=live}}</ref>

In January 2016, [[Telegram (software)|Telegram]] started re-encoding all GIFs to [[MPEG-4]] videos that "require up to 95% less disk space for the same image quality."<ref>{{cite web|title=GIF Revolution|url=https://telegram.org/blog/gif-revolution|website=Official Telegram Blog|date=4 January 2016|access-date=4 January 2016|archive-date=10 January 2016|archive-url=https://web.archive.org/web/20160110202119/https://telegram.org/blog/gif-revolution|url-status=live}}</ref>

==See also==
{{portal|Internet|Animation}}
* [[AVIF]]
* [[Cinemagraph]], a partially animated photograph often in GIF
* [[Web beacon|Clear GIF]], a technique used to check content access
* [[Comparison of graphics file formats]]
* [[GIF art]], a form of [[digital art]] associated with GIF
* [[GIFBuilder]], early [[animated GIF]] creation program
* [[plotutils|GNU plotutils]] (supports pseudo-GIF, which uses [[run-length encoding]] rather than LZW)
* [[Microsoft GIF Animator]], historic program to create simple animated GIFs
* [[Software patent]]

==References==
{{Reflist}}

==External links==
{{Commons category|GIF file format}}
* [http://giflib.sourceforge.net/ The GIFLIB project]
* [https://www.w3.org/Graphics/GIF/spec-gif89a.txt spec-gif89a.txt] GIF 89a specification on [[w3.org]]
* [https://web.archive.org/web/20160304075538/http://qalle.net/gif89a.php GIF 89a specification reformatted into HTML]
* [https://www.eecis.udel.edu/~amer/CISC651/lzw.and.gif.explained.html LZW and GIF explained]
* [https://www.pbs.org/video/2207348428/ Animated GIFs]: a six-minute documentary produced by [[Off Book (web series)]]
* [https://gifcities.org GifCities] (The GeoCities Animated GIF Search Engine)

{{Graphics file formats}}
{{Compression formats}}

[[Category:Animated graphics file formats]]
[[Category:Raster graphics file formats]]
[[Category:CompuServe]]
[[Category:Open formats]]
[[Category:Computer-related introductions in 1987]]
[[Category:Discovery and invention controversies]]